sablevm-developer Mailing List for SableVM (Page 61)
Brought to you by:
egagnon
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(27) |
Aug
(22) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(30) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(32) |
Oct
|
Nov
|
Dec
|
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(69) |
Sep
(10) |
Oct
(31) |
Nov
(15) |
Dec
(58) |
2003 |
Jan
(33) |
Feb
(81) |
Mar
(85) |
Apr
(24) |
May
(15) |
Jun
(14) |
Jul
(6) |
Aug
(9) |
Sep
(101) |
Oct
(59) |
Nov
(142) |
Dec
(34) |
2004 |
Jan
(107) |
Feb
(164) |
Mar
(181) |
Apr
(96) |
May
(81) |
Jun
(71) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Etienne M. G. <eti...@uq...> - 2001-09-17 17:05:27
|
I think I forgot to add a few things in configure.ac (I will copy them over from sablevm's), e.g. AC_DEFINE(_REENTRANT,1,link with reentrant library functions) This define is critical to good operation in a multithreaded environment. Well designed libraries relieve "programmers" from the burden of calling the "right" function when this is defined... I will also add my usual gcc set of compile options. Etienne On Mon, Sep 17, 2001 at 05:49:41PM +0100, John Leuner wrote: > > Hi Etienne, > > > > Thanks for the pointer. dtoa.c fixed the _Jv_dtoa issue. To fix the > > _Jv_strtod_r I had to define KISSME_LINUX_USER for the file > > src/java-lang/java_lang_Double.c (well I altered it to a #if 1). > > Shouldn't this be picked up by the configure script? Thanks again, > > Hmm, I think that's there because gcj was using it's own reentrant method. > > It should be named something else. > > John Leuner > -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: John L. <je...@pi...> - 2001-09-17 16:56:08
|
> Hi Etienne, > > Thanks for the pointer. dtoa.c fixed the _Jv_dtoa issue. To fix the > _Jv_strtod_r I had to define KISSME_LINUX_USER for the file > src/java-lang/java_lang_Double.c (well I altered it to a #if 1). > Shouldn't this be picked up by the configure script? Thanks again, Hmm, I think that's there because gcj was using it's own reentrant method. It should be named something else. John Leuner |
From: Ian R. <ir...@cs...> - 2001-09-17 16:13:53
|
Hi Etienne, Thanks for the pointer. dtoa.c fixed the _Jv_dtoa issue. To fix the _Jv_strtod_r I had to define KISSME_LINUX_USER for the file src/java-lang/java_lang_Double.c (well I altered it to a #if 1). Shouldn't this be picked up by the configure script? Thanks again, Ian |
From: Etienne M. G. <eti...@uq...> - 2001-09-17 04:27:21
|
Hi Ian, I am guilty of not trying to link the different libraries. You should try moving src/unused/jni/dtoa.c to src/java-lang/dtoa.c, then adding dtoa.c in Makefile.am. Let me know if this helps, so that I go and fix the classpath extraction scripts. If you have similar problems, you can always look in the src/unused directory for missing struff. Another possibility is missing "-l" compilation directives (to link with system libraries) in Makefile.am. Thanks, Etienne On Sat, Sep 15, 2001 at 11:10:39PM +0000, Ian Rogers wrote: > Hi, > > Has anyone resolved the following linking problems I'm having with > java-lang: > > /home/ian/lib/sablepath-libs/libjava-lang.so: undefined reference to > `_Jv_strtod_r' > /home/ian/lib/sablepath-libs/libjava-lang.so: undefined reference to > `_Jv_dtoa' > > I think I'm up to date with everything and I've tried the > java_lang_Double.c and mprec.[ch] sources from classpath. > > Thanks, > > Ian Rogers > > _______________________________________________ > Sablevm-developer mailing list > Sab...@li... > https://lists.sourceforge.net/lists/listinfo/sablevm-developer -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Ian R. <ir...@cs...> - 2001-09-15 22:14:01
|
Hi, Has anyone resolved the following linking problems I'm having with java-lang: /home/ian/lib/sablepath-libs/libjava-lang.so: undefined reference to `_Jv_strtod_r' /home/ian/lib/sablepath-libs/libjava-lang.so: undefined reference to `_Jv_dtoa' I think I'm up to date with everything and I've tried the java_lang_Double.c and mprec.[ch] sources from classpath. Thanks, Ian Rogers |
From: Ian R. <ir...@cs...> - 2001-09-14 16:09:25
|
Hi, > If you want to checkin your improvements to Sablepath in CVS, you > need to get this auto* stuff working. It's working, sorry, some shell weirdness. I can see why you've moved to the latest tools, it's a shame these migrations are never totally clean. I.e. parts of my previously stable SuSE 7.2 installation are now broken unless I mess around with PATHs (nothing too important's broken though, I think). I've never had the patience for Debian. > If it is a simple thing to fix, you could modify BreakIterator.java, > then add: > > Modification (C) 2001 Ian... <email>. > > just below the FSF's copyright, then do a "cvs commit"? For sure, I expect this is just some libgcj syncing issue though. Classpath probably is just lagging and the issue will be resolved soon enough. I'm surprised BreakIterator is building for you though. Ahwell.. All the best, Ian |
From: Etienne M. G. <eti...@uq...> - 2001-09-14 15:46:26
|
On Thu, Sep 13, 2001 at 09:17:25PM +0000, Ian Rogers wrote: > I haven't. TBH, I've had difficulty with all the latest autoconf, etc. I Have you tried downloading these auto* from ftp.gnu.org:/pub/gnu/auto* (replacing auto* by autoconf, automake, libtool) and installing them in your PATH? > usually try and avoid the bleeding edge and stick with more stable > distributions. My problem is that I migrated to Debian unstable to get packages like libffi-dev and the latest glibc and Linux kernel 2.4 with better multithreading support. Because the intruduction of autoconf 2.50, the configure syntax has changed, so I migrated it for SableVM ... > WRT autoconf for some reason libtool isn't geting set up > properly, even tho' I've rebuilt that and everything else I'm missing > the necessary macro definitions. If you made a local installation, you should make sure your C_INCLUDE_PATH and similar environment variables are correctly set. Here's the list: LIBRARY_PATH LD_LIBRARY_PATH C_INCLUDE_PATH > I'm sure I'll track the problem down in > the end. I'd have prefered not to have to, but I don't like having to > rely on the prebuilt configure script in the tgz. Ohwell.. > If you want to checkin your improvements to Sablepath in CVS, you need to get this auto* stuff working. > The problems with java/text/BreakIterator.java are the references to > gnu.java.text.* which simply doesn't exist in the sablepath CVS tree. If > jikes 1.13 is building BreakIterator then it is more slack in allowing > classes to be built with undefined references in them than jikes 1.12. > Let me know your thoughts. If it is a simple thing to fix, you could modify BreakIterator.java, then add: Modification (C) 2001 Ian... <email>. just below the FSF's copyright, then do a "cvs commit"? Have fun! Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Ian R. <ir...@cs...> - 2001-09-13 20:20:53
|
Hi Etienne, > Have you tried upgrading to Jikes 1.13? You can download it (source > .tar.gz) from www.jikes.org (redirects to the long ibm url). I haven't. TBH, I've had difficulty with all the latest autoconf, etc. I usually try and avoid the bleeding edge and stick with more stable distributions. WRT autoconf for some reason libtool isn't geting set up properly, even tho' I've rebuilt that and everything else I'm missing the necessary macro definitions. I'm sure I'll track the problem down in the end. I'd have prefered not to have to, but I don't like having to rely on the prebuilt configure script in the tgz. Ohwell.. The problems with java/text/BreakIterator.java are the references to gnu.java.text.* which simply doesn't exist in the sablepath CVS tree. If jikes 1.13 is building BreakIterator then it is more slack in allowing classes to be built with undefined references in them than jikes 1.12. Let me know your thoughts. All the best, Ian Rogers |
From: Etienne M. G. <eti...@uq...> - 2001-09-13 19:41:37
|
Hi Ian, Have you tried upgrading to Jikes 1.13? You can download it (source .tar.gz) from www.jikes.org (redirects to the long ibm url). As usual, you compile it with "./configure; make install" On my system, jikes 1.13 compiles java/text/BreakIterator.java without any problem. Etienne Ian Rogers wrote: > I have difficulty building java/text/BreakIterator.java and have added > it to my broken classes list to get the current CVS image to build. > > Ian > > _______________________________________________ > Sablevm-developer mailing list > Sab...@li... > https://lists.sourceforge.net/lists/listinfo/sablevm-developer > > . > > -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Ian R. <ir...@cs...> - 2001-09-13 14:26:24
|
I have difficulty building java/text/BreakIterator.java and have added it to my broken classes list to get the current CVS image to build. Ian |
From: Etienne M. G. <eti...@uq...> - 2001-09-11 02:56:21
|
Hi, I've finally managed to get the auto* stuff working for sablepath-libs. Debian's packages for the newest auto* tools are bronken, but if you download from ftp.gnu.org and install these packages, they work well. For those who don't like to work with these tools, I have made a prepackaged version of sablepath-[classes/libs] available on the web site: http://sourceforge.net/project/showfiles.php?group_id=5523&release_id=52287 Have fun! Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Etienne M. G. <eti...@UQ...> - 2001-09-10 12:07:17
|
Hi Ian! You can start playing with sablepath-libs: $ cvs update -PRd $ aclocal; autoconf ; autoheader ; automake -a $ ./configure --prefix=/home/ian/somedirectory $ make $ make install Please let me know of any problem. [I have some: make distcheck fails... :( ] Etienne -- Etienne M. Gagnon http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Etienne M. G. <eti...@uq...> - 2001-09-04 14:02:31
|
On Tue, Sep 04, 2001 at 12:02:50PM +0000, Ian Rogers wrote: > I checked it out and everything built for me just fine. I couldn't > (didn't try too hard) to get jakarta-ant to build for me, so I just used > the binary version. But yep, great :-) I don't like much ant's packaging. I will probably make a simpler package for people to build/install. I need to do this, anyway, for my students, as I do not want them to fight with the system to get ant & xerxes installed; they're new to Java:) As Tuesday is my teaching day, I won't be able to accomplish much today. Please be forgiving. > I don't actually need java.util.zip (I think). It may just be worth > waiting for classpath to integrate jazzlib. If that takes too long then > we can integrate it, but it should probably be a low priority unless > there is a particular need. I'd like, at some point, to have the system class-loader (which is NOT the bootstrap class-loader, and IS written in java) to load classes out of jar files. The zip stuff would be great for this. But it can wait a little. Would you try contacting the 2 persons Brian refered to in his reply to me? Maybe they're on vacation, or inactive, or whatever; so it would be a good idea to check that they are aware that people are waiting for action. It is my experience that when Brian says that somebody is responsible for something, it means that he himself is not responsible for it; it does not necessarily mean that he will do anything to contact the responsible person and try to get things moving... > > - I've modified "build.xml" so that it does not try to compile the > > classes > > listed in the file "broken-classes" (new also). > > Works a treat. So, are you sold on not using the GNU auto* stuff for Java code? It was a SableCC user that introduced me to Ant. Once you get to know it, you don't want to go back to Makefiles (or GNU auto*) for your Java projects. > OK, I'm playing with sablepath-libs now. I'll let you know of problems I > find with them and SpecJVM. Ta, Hmmm... I haven't updated sablepath-libs with the latest Classpaht CVS snapshot. I still have to adapt my "extracting" scripts for the latest code. But, you can certainly have a quick look, to see how I think the code should be organized. Mainly, I organize the code into one directory for every .so library that can be loaded through System.loadLibrary(). Etienne -- Etienne M. Gagnon eti...@uq... SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Ian R. <ir...@cs...> - 2001-09-04 11:02:36
|
Hi, > - I've imported the latest classpath updates into CVS. I checked it out and everything built for me just fine. I couldn't (didn't try too hard) to get jakarta-ant to build for me, so I just used the binary version. But yep, great :-) > - I've checked the http://jazzlib.sourceforge.net/ project. Their > zip stuff is under a compatible license, and copyrighted by the FSF. I > could import their latest CVS snapshot (as their latest release is > rather > old) into another vendor branch, as I do with classpath. What do you > think? I don't actually need java.util.zip (I think). It may just be worth waiting for classpath to integrate jazzlib. If that takes too long then we can integrate it, but it should probably be a low priority unless there is a particular need. > - I've modified "build.xml" so that it does not try to compile the > classes > listed in the file "broken-classes" (new also). Works a treat. OK, I'm playing with sablepath-libs now. I'll let you know of problems I find with them and SpecJVM. Ta, Ian |
From: Etienne M. G. <eg...@j-...> - 2001-09-03 23:50:05
|
- I've imported the latest classpath updates into CVS. - Jikes 1.13 works fine for me. I think 1.14 introduced some locale stuff which somehow creates prolems on Debian. Others are following upon this on Debian (and probably jikes) so I won't waste my time on this. - I've checked the http://jazzlib.sourceforge.net/ project. Their zip stuff is under a compatible license, and copyrighted by the FSF. I could import their latest CVS snapshot (as their latest release is rather old) into another vendor branch, as I do with classpath. What do you think? - I've modified "build.xml" so that it does not try to compile the classes listed in the file "broken-classes" (new also). For those of you who don't know about it, there's a cvs-commit mailing-list so that you get notified on every update. You can subscribe for the daily digest option if you do not want to be flooded by mail on multiple updates. See the mailing-list collection at: http://sourceforge.net/mail/?group_id=5523 Have fun! Etienne -- Etienne M. Gagnon eg...@j-... SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: <eg...@j-...> - 2001-09-03 19:32:01
|
Hi Ian, On Fri, Aug 31, 2001 at 05:43:24PM +0000, Ian Rogers wrote: > files I'm running "find src -name '*.java'|xargs jikes +E -classpath > /home/ian/sable/sablepath-classes/src:/home/ian/old-classpath". Jikes > version 1.2. The story so far: I have tried recompiling jikes 1.14 from sources, but it didn't solve the segmentation fault problem. I have noticed that there's a bug report on the Debian package I was using, relatively to this problem, so I grabbed the sources from : http://oss.software.ibm.com/developerworks/project/showfiles.php?group_id=10 The problem is that jikes 1.02 is not available there. Do you have a copy of this packages (sources)? > The jar stuff relies on java/util/zip which for some reason isn't in the > classpath repository. If it were I'm confident this would build. I've noticed your request on the classpath-list. Hopefully people will finally check-in those sources. > > src/java/net/URLClassLoader.java > > Built fine for me. Possible issues with the Jar stuff tho'. I need to get a version of jikes that does not sigfaults. Maybe it is related to the fact I have GNU LibC 2.2.4 on my system? > I'm running a slightly older version of Jikes and things appear to be > fine. I'm keen to keep using this older version of Jikes too, until > someone points out a really good reason to upgrade. My problem is that I'm on Debian "unstable" which keeps updating to the latest "stable" version of programs (which means 1.14 for Jikes)... I can always do a local installation, out of source packages too, but I didn't find version 1.02. I'll try the oldest one available 1.04 and report back success/failure. > In summary, everything is there and building except Swing and the Jar > related stuff. As some of the core stuff relies on the Jar stuff I'm > keen we get that working. I'll e-mail the maintainer and hopefully find > out when the stuff will appear in the classpath CVS repository. The > Swing stuff isn't critical to me, and it appears very incomplete. I > suggest we move it out of the code tree for the time being. > > Finally, the way I'm building the code at the moment puts all the > pressure on jikes. Should we build a set of makefiles, configure, etc.. > ? The "build.xml" file is the equivalent of Makefile.am/configure.ac files. It is for use with the Jakarta "ant" tool. See http://jakarta.apache.org/ant/ This tool is written in Java, and offers a much more appropriate way to build classes, jar files, and distributions for Java programs than the GNU auto-tools. It has a pretty simple "XML" based syntax. We can use it to "exclude" from compilation those files we know not to build. My problem was that, on my system, jikes failed to compile too many classes. Currently, I use Sun's jdk to "run ant". Hopefully, someday soon I'll be able to run it on SableVM instead. Obviously, we will also need to provide a simple script to bootstrap the first compilation on a user system;-) But for maintenance, ant is a charm to use (for the Java part). Obviously, we want to maintain the JNI/C code under the GNU auto* tools. This is why I have made a separate sablepath-lib CVS project for it. You could give Ant a look and ask me any question you have. I'll get back as soon as I can get jikes to work decently on my system. If you have made any modifications to the sources, you can check-them in CVS. If you have Ant running, you can add an "exclude" specification in the <javac ...> task so to exclude the files you "moved away" in your local copy. Have fun! Etienne -- Etienne M. Gagnon eg...@j-... SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Ian R. <ir...@cs...> - 2001-08-31 17:19:16
|
Hi, Here's a summary of where I'm up to. I'm trying my best to build the sablepath-classes with a standard SuSE 7.2 set up. To build the .class files I'm running "find src -name '*.java'|xargs jikes +E -classpath /home/ian/sable/sablepath-classes/src:/home/ian/old-classpath". Jikes version 1.2. The story so far: > src/java/util/jar/JarEntry.java > src/java/util/jar/JarFile.java > src/java/util/jar/JarInputStream.java > src/java/util/jar/JarOutputStream.java > src/java/net/JarURLConnection.java The jar stuff relies on java/util/zip which for some reason isn't in the classpath repository. If it were I'm confident this would build. > src/java/net/URLClassLoader.java Built fine for me. Possible issues with the Jar stuff tho'. > src/java/util/IdentityHashMap.java The clone method needs to have "throws java/lang/CloneNotSupportedException" appended. I guess Object.clone was updated and this file was missed during the update. > src/javax/swing/plaf/BorderUIResource.java Wouldn't compile so moved out of the build tree. Issues mainly with a border package. > src/javax/swing/GrayFilter.java Compiled fine when the body of createDisabledImage was altered to return null; and filterRGB's result was cast to an int. > src/javax/accessibility/AccessibleText.java > src/javax/accessibility/Accessible.java > src/javax/accessibility/AccessibleHypertext.java There's clearly issues with javax/accessibility. I moved these files. > src/javax/accessibility/AccessibleComponent.java > src/javax/accessibility/AccessibleSelection.java Compiled fine for me, but failed when the other files were moved. > src/gnu/javax/swing/plaf/gtk/GtkIconFactory.java Failed most notably because java/swing/plaf/gtk/Icon was misssing, therefore moved. > src/gnu/javax/swing/plaf/gtk/GtkSliderUI.java > src/gnu/javax/swing/plaf/gtk/GtkLookAndFeel.java > src/gnu/javax/swing/plaf/gtk/GtkRadioButtonUI.java > src/gnu/javax/swing/plaf/gtk/GtkBorders.java > src/gnu/javax/swing/plaf/gtk/GtkCheckBoxUI.java Failed for lots of reasons, javax/swing/plaf/basic and javax/swing/border not being present being one of them, files moved. > I have not looked for the reason why these are broken. More annoying is the > fact that many classes, including "core" library classes (I think java.io.File > is part of them) are broken under Jikes. Jikes seems to die with something > like a "signal 11". I'm running a slightly older version of Jikes and things appear to be fine. I'm keen to keep using this older version of Jikes too, until someone points out a really good reason to upgrade. In summary, everything is there and building except Swing and the Jar related stuff. As some of the core stuff relies on the Jar stuff I'm keen we get that working. I'll e-mail the maintainer and hopefully find out when the stuff will appear in the classpath CVS repository. The Swing stuff isn't critical to me, and it appears very incomplete. I suggest we move it out of the code tree for the time being. Finally, the way I'm building the code at the moment puts all the pressure on jikes. Should we build a set of makefiles, configure, etc.. ? All the best, Ian Rogers |
From: Etienne M. G. <eti...@uq...> - 2001-08-27 20:21:24
|
Hi. Lately, I have imported the latest sources from the Classpath repository into sablepath-classes, using scripts to extract java sources (and related resource files) and relocate them in a sane directory structure. I- === One thing I would like to have is a code indenter, somethink akin "indent". This would simplify code maintenance as we could run the indenter along the "import" scripts so that diffs with the vendor CVS branch wouldn't be artificially inflated by simple code re-indentation. Also, it makes life simpler for everybody to have a uniform indentation style. Personally, I would like a program that indents programs closely to the "GNU C" style, with matching parenthesis level, one space between identifier/keyword and "(", with minor modifications... something like: void foo (int a, long b) { ... } *** NOT *** void foo( int a , long b ) { ... } Anyone knows a *** robust *** program to do so? All the ones I have tried so far have bugs when confronted to inner-classes/anonymous classes, or are not flexible using Sun's ugly unmatched "{" "}" levels, etc. II- === The latest Classpath source files are mostly broken under Jikes (I'm using version 1.14). So I have cheated, and tried compiling them under "javac". [I am not checking that semantics are OK, just that they compile]. Even this is asking a lot from Classpath... There are 20 classes that are definitely broken. Here is the list: src/gnu/javax/swing/plaf/gtk/GtkBorders.java src/gnu/javax/swing/plaf/gtk/GtkCheckBoxUI.java src/gnu/javax/swing/plaf/gtk/GtkIconFactory.java src/gnu/javax/swing/plaf/gtk/GtkLookAndFeel.java src/gnu/javax/swing/plaf/gtk/GtkRadioButtonUI.java src/gnu/javax/swing/plaf/gtk/GtkSliderUI.java src/java/util/jar/JarEntry.java src/java/util/jar/JarFile.java src/java/util/jar/JarInputStream.java src/java/util/jar/JarOutputStream.java src/javax/accessibility/Accessible.java src/javax/accessibility/AccessibleHypertext.java src/javax/accessibility/AccessibleText.java src/javax/swing/GrayFilter.java src/javax/swing/plaf/BorderUIResource.java src/java/net/JarURLConnection.java src/javax/accessibility/AccessibleComponent.java src/javax/accessibility/AccessibleSelection.java src/java/net/URLClassLoader.java src/java/util/IdentityHashMap.java I have not looked for the reason why these are broken. More annoying is the fact that many classes, including "core" library classes (I think java.io.File is part of them) are broken under Jikes. Jikes seems to die with something like a "signal 11". As usual, you must be careful to set BOTH the "-bootclasspath" and "-classpath" command line options to for the compiler to use "SablePath" as its core system library when you compile the code (with jikes and/or javac). All help/suggestions would be appreciated. Have fun, Etienne -- Etienne M. Gagnon eti...@uq... SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Etienne M. G. <eg...@j-...> - 2001-01-12 16:21:21
|
Hi John, I am currently working on locks, and many other things. I am planning for a release in late January. This is a hard deadline as I also have to get some numbers for an accepted JVM'01 paper (http: http://www.usenix.org/events/jvm01/). I had to make many changes within SableVM to implement the paper's popositions. The two word object header will contain many things beyond the thin lock. Also, I was planning to use a single inlined function for the compare-and-swap operation (your code uses more than a single line of inlined asm). If you can wait a couple of weeks, you should get something worth working with. Etienne John Leuner wrote: > > > John Leuner wrote: > > > Have you implemented object locks in SableVM yet? I have had a quick look > > > at the source and didn't find anything there. > > > > Not yet. I have spent too much time writing about SableVM (tech report > > & Ph.D. proposal & presentation slides), and participating to seminars. > > Before I go forward with it, I want to get single threading in a much > > better state. I think that getting exceptions to work, and cleaning the > > memory management code has higher priority. > > > > Do you want to help with implementing locks? I can give you a few > > pointers (in addition to my tech report). > > I'ld like to make a lock implementation for my JVM (kissme), but of course > it should be easy to use in SableVM too. > > So far I have written code to do the atomic test and set: > > (pstObject is the handle to the object we want to lock) > { > //we must do an atomic test and set > int before; > int temp_word; > > //set high bit to 1 > //set bit 23 to 1 > temp_word = 0x80800001; > //set the bits 8-21 to the thread identifier > temp_word |= ( (pthread_self() << 8) & 0x007fff00); > > eprintf("Before lock it is %x and temp_word is %x\n", > ODEREF(pstObject)->lock_word, temp_word); > before = ODEREF(pstObject)->lock_word; > > if(before == 0) //object is unlocked > { > //set eax to 0 > //compare ecx to eax, if they are the same, then copy temp_word > to ecx > __asm__ __volatile__ ( > "movl $0x0, %%eax ; \n" > "movl %1, %%ecx ; \n" > " cmpxchg %%ecx,%0 ; \n" > : "=r" (ODEREF(pstObject)->lock_word) > : "r" (temp_word) , > "0" (ODEREF(pstObject)->lock_word) > : "ax","cx" > ); > } > else > { > if( (ODEREF(pstObject)->lock_word & 0x007fff00) == ( > (pthread_self() << 8) & 0x007fff00)) > { > //we own the lock > //so we just increment the count > temp_word = before + 1; > __asm__ __volatile__ ( > "movl %3, %%eax ; \n" > "movl %1, %%ecx ; \n" > " cmpxchg %%ecx,%0 ; \n" > : "=r" (ODEREF(pstObject)->lock_word) > : "r" (temp_word) , > "0" (ODEREF(pstObject)->lock_word) , "r" (before) > : "ax","cx" > ); > //again we must check if we succeeded > if(temp_word == ODEREF(pstObject)->lock_word) > { > eprintf("Succeeded in doing inc atomic lock\n"); > } > else > { > eprintf("Tried to do incremental lock but failed %x\n", > ODEREF(pstObject)->lock_word); > assert( 4 == 0); > } > } > else //we aren't the owner > { > eprintf("we don't own this lock!!!!\n"); > } > } > > //check if we succeeded > if(temp_word == ODEREF(pstObject)->lock_word) > { > eprintf("Succeeded in doing atomic lock %x\n", > ODEREF(pstObject)->lock_word); > } > else > { > eprintf("Failed in doing atomic lock it is %x and temp_word is %x\n", > ODEREF(pstObject)->lock_word, temp_word)\; > //this means either we, or someone else, owns the lock > > assert( 2 == 3); > } > > I'm reading the report and I'm not sure how a thin lock is inflated to a > fat lock. This is what I have in mind for the contention case: > > if lock is owned by another thread > get owning thread identifier > get thread structure for owning thread > acquire lock for owning thread > set contention bit in thread structure > if lock is still thin and owned by that thread > add tuple to owning threads wait list > sleep (on what?) > else > restore contention bit > release lock for owning thread > repeat this > end > > So does a lock get inflated only during an unlock operation? When it is > inflated, do we use the high bit to distinguish between a thin and fat > lock? Is the fat lock just a pthread_mutex_t on linux? Do we use the lock > word for this? > > John Leuner > > _______________________________________________ > Sablevm-developer mailing list > Sab...@li... > http://lists.sourceforge.net/lists/listinfo/sablevm-developer -- ---------------------------------------------------------------------- Etienne M. Gagnon, M.Sc. e-mail: eg...@j-... Author of SableCC: http://www.sablecc.org/ and SableVM: http://www.sablevm.org/ |
From: John L. <je...@pi...> - 2001-01-12 16:09:57
|
> John Leuner wrote: > > Have you implemented object locks in SableVM yet? I have had a quick look > > at the source and didn't find anything there. > > Not yet. I have spent too much time writing about SableVM (tech report > & Ph.D. proposal & presentation slides), and participating to seminars. > Before I go forward with it, I want to get single threading in a much > better state. I think that getting exceptions to work, and cleaning the > memory management code has higher priority. > > Do you want to help with implementing locks? I can give you a few > pointers (in addition to my tech report). I'ld like to make a lock implementation for my JVM (kissme), but of course it should be easy to use in SableVM too. So far I have written code to do the atomic test and set: (pstObject is the handle to the object we want to lock) { //we must do an atomic test and set int before; int temp_word; //set high bit to 1 //set bit 23 to 1 temp_word = 0x80800001; //set the bits 8-21 to the thread identifier temp_word |= ( (pthread_self() << 8) & 0x007fff00); eprintf("Before lock it is %x and temp_word is %x\n", ODEREF(pstObject)->lock_word, temp_word); before = ODEREF(pstObject)->lock_word; if(before == 0) //object is unlocked { //set eax to 0 //compare ecx to eax, if they are the same, then copy temp_word to ecx __asm__ __volatile__ ( "movl $0x0, %%eax ; \n" "movl %1, %%ecx ; \n" " cmpxchg %%ecx,%0 ; \n" : "=r" (ODEREF(pstObject)->lock_word) : "r" (temp_word) , "0" (ODEREF(pstObject)->lock_word) : "ax","cx" ); } else { if( (ODEREF(pstObject)->lock_word & 0x007fff00) == ( (pthread_self() << 8) & 0x007fff00)) { //we own the lock //so we just increment the count temp_word = before + 1; __asm__ __volatile__ ( "movl %3, %%eax ; \n" "movl %1, %%ecx ; \n" " cmpxchg %%ecx,%0 ; \n" : "=r" (ODEREF(pstObject)->lock_word) : "r" (temp_word) , "0" (ODEREF(pstObject)->lock_word) , "r" (before) : "ax","cx" ); //again we must check if we succeeded if(temp_word == ODEREF(pstObject)->lock_word) { eprintf("Succeeded in doing inc atomic lock\n"); } else { eprintf("Tried to do incremental lock but failed %x\n", ODEREF(pstObject)->lock_word); assert( 4 == 0); } } else //we aren't the owner { eprintf("we don't own this lock!!!!\n"); } } //check if we succeeded if(temp_word == ODEREF(pstObject)->lock_word) { eprintf("Succeeded in doing atomic lock %x\n", ODEREF(pstObject)->lock_word); } else { eprintf("Failed in doing atomic lock it is %x and temp_word is %x\n", ODEREF(pstObject)->lock_word, temp_word)\; //this means either we, or someone else, owns the lock assert( 2 == 3); } I'm reading the report and I'm not sure how a thin lock is inflated to a fat lock. This is what I have in mind for the contention case: if lock is owned by another thread get owning thread identifier get thread structure for owning thread acquire lock for owning thread set contention bit in thread structure if lock is still thin and owned by that thread add tuple to owning threads wait list sleep (on what?) else restore contention bit release lock for owning thread repeat this end So does a lock get inflated only during an unlock operation? When it is inflated, do we use the high bit to distinguish between a thin and fat lock? Is the fat lock just a pthread_mutex_t on linux? Do we use the lock word for this? John Leuner |
From: Etienne M. G. <eg...@j-...> - 2000-12-13 03:31:27
|
Brent Fulgham wrote: > Have any of your seen the PocketLinux project? They are taking > various palm devices and installing a Linux kernel along with > the Kaffe Virtual Machine. I have even seen one machine at OOPSLA. A former McGill student, that I know, works at Transvirtual. He was at OOPSLA and showed me one of the little cute machines. > Anyway, I'll just bet SableVM could work on that device > as well, if we ported all appropriate native classes. > (Obviously this will wait until SableVM's functionality is > better on a full-fledged machine)! I definitely hope it will work on such device! Etienne -- ---------------------------------------------------------------------- Etienne M. Gagnon, M.Sc. e-mail: eg...@j-... Author of SableCC: http://www.sable.mcgill.ca/sablecc/ and SableVM: http://www.sablevm.org/ ---------------------------------------------------------------------- |
From: Brent F. <bre...@xp...> - 2000-12-12 23:05:57
|
Have any of your seen the PocketLinux project? They are taking various palm devices and installing a Linux kernel along with the Kaffe Virtual Machine. Apparently, most applications (and the handwriting recognition software) are written Java: http://www.pocketlinux.com/ The really neat thing is that you can pick up a VTech Helio palm device (which retails for $149) and install this stuff. With a 75Mhz Risc chip, 8 Megs of RAM (+ 2 Megs of flash storage) that's quite a nice little unit. An interesting contrast is my first "powerful" PC (which I used to write my Masters Thesis). It was a 25 Mhz Intel 386, with 8 Megs of RAM and a "large" 40 Meg Hard Disk. I haggled the sales people down to about $1,300 for that little beauty! Anyway, I'll just bet SableVM could work on that device as well, if we ported all appropriate native classes. (Obviously this will wait until SableVM's functionality is better on a full-fledged machine)! -Brent |
From: Etienne M. G. <eg...@j-...> - 2000-12-12 22:03:08
|
Brent Fulgham wrote: > Oh yes -- a valid directory yields a good result. I'm just saying > that if the user sets garbage in the configuration it does not > recover from this. (And I'm not sure how far you want to go in > bulletproofing it -- should you protect against the user deleting > the directory after the first read, etc.? ;-)) It's OK. Even if there's garbage there, the VM will behave as expected; it shouldn't segfault, but throw a "class not found" error. If this happens in the VM creation (JNI_CreateVM), the function should simply fail. Nothing special about it. > Whee! Just did it. At least one thing that works on SF, these days... The "release" process, and some mailing-list features are broken, with no known ETA for the fix. Etienne -- ---------------------------------------------------------------------- Etienne M. Gagnon, M.Sc. e-mail: eg...@j-... Author of SableCC: http://www.sable.mcgill.ca/sablecc/ and SableVM: http://www.sablevm.org/ ---------------------------------------------------------------------- |
From: Brent F. <bre...@xp...> - 2000-12-12 21:34:38
|
> Now, when you build a binary package, for inclusion in an official > distribution, you simply use some configure options to put > files in the right directory, according to the policy of your > distribution. > > ./configure --prefix=/ --sysconfdir=/etc ... > > I haven't built any binary package for a distribution, yet > (except for a Debian kernel package), so I do not know how people > usually go about it, but I am pretty sure that they do something > similar. Maybe you know more than me about that;-) > Looks like you know about as much as I do :-) > > > > I tried out your test cases, and I'm happy to report that the code > > does read and store your 3095-byte test string. Unfortunately, it > > seems to cause a segfault later on when the JVM attempts to > > stat that non-existent directory... > > Have you tested giving sablevm an appropriate boot-class-path and > boot-library-path? > > It works for me, without segfaulting... > Oh yes -- a valid directory yields a good result. I'm just saying that if the user sets garbage in the configuration it does not recover from this. (And I'm not sure how far you want to go in bulletproofing it -- should you protect against the user deleting the directory after the first read, etc.? ;-)) > I'll let you close the bugs, testing your new privileges:-) > Whee! Just did it. -Brent |
From: Etienne M. G. <eg...@j-...> - 2000-12-12 21:05:17
|
"Etienne M. Gagnon" wrote: > OK. So, you'll get admin privilege. You, and all other developers, are "bug" and "patch" admins. Use your new powers with care. :-))) Etienne -- ---------------------------------------------------------------------- Etienne M. Gagnon, M.Sc. e-mail: eg...@j-... Author of SableCC: http://www.sable.mcgill.ca/sablecc/ and SableVM: http://www.sablevm.org/ ---------------------------------------------------------------------- |