Thread: [Sablevm-developer] Alpha inlined threading works now, but...
Brought to you by:
egagnon
Menu
▾
▴
sablevm-developer
|
From: Grzegorz B. P. <ga...@de...> - 2003-02-19 01:24:53
|
Hi! I'll be dead man walking tomorrow... but I have to say it. At #d-d I meet mellum <fa...@de...> which had alpla machine. Compiling simply with --with-threading=3Dinlined was giving segfaults [unfortunatelly build was done with dh_strip, so we gdb was not useful] <mellum> SableVM version 1.0.5 <mellum> - signal based exception detection <mellum> - copying garbage collection <mellum> - bidirectional object layout <mellum> - inline-threaded interpreter [next builds were done w/o symbol stripping] So I added --enable-signals-for-exceptions=3Dno and debugging-features. It worked (!) <mellum> SableVM version 1.0.5 <mellum> - debugging checks enabled <mellum> - copying garbage collection <mellum> - bidirectional object layout <mellum> - inline-threaded interprete So I removed the debugging-features with hope that it'll still workd <mellum> SableVM version 1.0.5 <mellum> - copying garbage collection <mellum> - bidirectional object layout <mellum> - inline-threaded interpreter I must admit that I hoped that it'll crash in the same place as ia64, but it didn't. We didn't have enough time to debug the issue further. I'd like to get back to first, segfaulting version but with symbols and check what's the backtrace of failure. Summary: - we have inlined-threading engine working on alpha (YES!) - there are some problems with using signal based exceptions with inlined-threading engine though. Grzegorz B. Prokopski PS: May I ask how many arches that support inlined-threading we have now? Does it work on PowerPC yet? --=20 Grzegorz B. Prokopski <ga...@de...> Debian http://www.debian.org/ |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-02-19 04:24:22
|
Hi there! On Wed, Feb 19, 2003 at 02:23:48AM +0100, Grzegorz B. Prokopski wrote: > Summary: > - we have inlined-threading engine working on alpha (YES!) Super! > - there are some problems with using signal based exceptions > with inlined-threading engine though. I had to add a few "volatile" for signal related stuff, as gcc was reordering instructions across signal-triggering locations. > PS: May I ask how many arches that support inlined-threading we have > now? Does it work on PowerPC yet? Yes, inlined-threading works on PPC! I finally got it to work just a few minutes ago. :-)) I also fixed the libffi related problems so as to get rid of the LIBFFIBUG conditional. This fix could help on ia64, if it has the same byte order as PPC. OK, I'll check-in the code into CVS in a few minutes. Etienne --=20 Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Grzegorz B. P. <ga...@de...> - 2003-02-19 18:23:10
Attachments:
alpha.diff
|
W liście z śro, 19-02-2003, godz. 05:15, Prof. Etienne M. Gagnon pisze: > I had to add a few "volatile" for signal related stuff, as gcc was > reordering instructions across signal-triggering locations. This can help for alpha problems too. For now - I attached the patch that adds safe support for inlined threading for alpha and code for cache flush on ia64. > > PS: May I ask how many arches that support inlined-threading we have > > now? Does it work on PowerPC yet? > Yes, inlined-threading works on PPC! I finally got it to work just a > few minutes ago. :-)) Great! > I also fixed the libffi related problems so as to get rid of the > LIBFFIBUG conditional. This fix could help on ia64, if it has the > same byte order as PPC. No - ia64, as it's used by Linux, uses the same byte order as i386 and alpha. So if there are any problems with endianness - they will appear on PPC. > OK, I'll check-in the code into CVS in a few minutes. Could you please merge attached bits too? I'd like to ask about possible new release features and timeframe. If you had enough resources, I'd love to see there: - merge of reflection stuff (already done FWICS) - merge of PPC sutff (already done FWICS) - merge of alpha stuff - update to new gnu classpath release As I'd like to get new release with _fixes_ ASAP - I think the last thing could be postponed for later time. Not that I want to push you to do sth, but can you release today? ;-) <reminder mode=whining> It's of course fun to play with portability etc., but I'd like to bring back the fact that for the people it's still hard to use SableVM because... free java packages are getting compiled with newer jikes which makes them unusable with current SableVM. That way - even having the reflection stuff in place - it may be impossible to run prepackaged ANT for example. :-( </reminder> Cheers, Grzegorz B. Prokopski PS: Do you have any suggestions for IA64 problems? (or at least why am I unable to setup brakpoint by name.c:xx?) It's a pity to make no use of a machine which is dedicated to get SableVM working. -- Grzegorz B. Prokopski <ga...@de...> Debian http://www.debian.org/ |
|
From: Grzegorz P. <gr...@se...> - 2003-02-19 18:40:15
|
W liście z śro, 19-02-2003, godz. 19:22, Grzegorz B. Prokopski pisze: > For now - I attached the patch that adds safe support for inlined > threading for alpha and code for cache flush on ia64. change all "alpha-*-gnu" to "alpha*-gnu" On a test alpha system type I can see is: alphapca56-unknown-linux-gnu GBP -- Grzegorz Prokopski <gr...@se...> |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-02-20 04:38:29
|
On Wed, Feb 19, 2003 at 07:22:04PM +0100, Grzegorz B. Prokopski wrote: > Could you please merge attached bits too? >=20 > I'd like to ask about possible new release features and timeframe. > If you had enough resources, I'd love to see there: > - merge of reflection stuff (already done FWICS) > - merge of PPC sutff (already done FWICS) > - merge of alpha stuff I'm working on this right now. > - update to new gnu classpath release I was planning to instead get the SableVM native/class library stuff into official Classpath CVS, instead of continuing to manage a vendor branch. But this might involve some political discussions on the Classpath ML first, as I'd like them to use indentation tools as I do in sablevm-*-library, which makes it so simpler to read and maintain code written by others. It could also affect the build process and directory layout... > As I'd like to get new release with _fixes_ ASAP - I think the last > thing could be postponed for later time. > Not that I want to push you to do sth, but can you release today? ;-) This is what I am working on. > <reminder mode=3Dwhining> > It's of course fun to play with portability etc., but I'd like to > bring back the fact that for the people it's still hard to use > SableVM because... free java packages are getting compiled with > newer jikes which makes them unusable with current SableVM. >=20 > That way - even having the reflection stuff in place - it may > be impossible to run prepackaged ANT for example. :-( > </reminder> I know. If I could only increase the number of hours to 25 hours per day;-) Maybe you could get the jikes maintainer to add a jikes1.15 package in unstable. I already tried, but I think he does not like the idea. > PS: Do you have any suggestions for IA64 problems? (or at least why am > I unable to setup brakpoint by name.c:xx?) It's a pity to make no use > of a machine which is dedicated to get SableVM working. Are you compiling SableVM using your .deb specific build process, or are you using the build-many script? I see no reason for the build-many script not to spit out debuggable code (for sablevm-debug). If you use your own build process, make sure ** not to call ** "make clean" betweem "make install" and "gdb sablevm", as many SableVM source files are automatically generated, and are deleted by "make clean". Etienne --=20 Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Archie C. <ar...@de...> - 2003-02-20 06:33:12
|
Prof. Etienne M. Gagnon wrote: > Maybe you could get the jikes maintainer to add a jikes1.15 package in > unstable. I already tried, but I think he does not like the idea. FWIW, I think practically speaking you could modify SableVM to accept classfiles with major version numbers up to 48 without any problems. I asked on the jikes mailing list about their changes and what spec they were reading from. Nobody could produce the spec, but I did get some useful info (see below). -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com > From jik...@ww... Sat Feb 15 10:20:01 2003 > From: Eric Blake <eb...@em...> > Subject: Re: [Jikes-dev] New class file format > To: jik...@ww... > Message-ID: <3E4...@em...> > MIME-Version: 1.0 > Content-Type: text/plain; format=flowed; charset=us-ascii > Content-Transfer-Encoding: 7bit > Sender: jik...@ww... > List-Archive: <http://www-124.ibm.com/pipermail/jikes-dev/> > Date: Sat, 15 Feb 2003 11:18:01 -0700 > Status: ORr > > Archie Cobbs wrote: > >> > >>So are you saying: the classfiles that jikes generates are exactly > >>the same - except for the major/minor version number - no matter > >>what -target flag is given? (If not, can you be specific about what > >>the differences are?) Is this also true for Sun's javac? > > > > To answer my own question: it appears to me from looking at the source > > that the only differences in the classfile is synthetic code generated > > to handle "Foo.class", e.g., using exception chaining. > > > > So the -target flag (so far) only "targets" the version of the base > > Java classes, rather than the virtual machine. > > > > Let me know if I've gotten myself confused :-) > > Read the source code in src/bytecode.cpp to see the different code > sequences that jikes outputs depending on the -target option (search for > control.option.target). For example, this code is different in 1.3 and 1.4: > > class A { > void m(final int i) { > class B { > int j = i; > } > } > } > > In 1.3, Sun's VM violated the JVMS, and didn't permit the initialization > of instance variables before calling the superconstructor. Therefore, > compiling with -target 1.3 will issue a constructor that looks like this > (this.this$0 and this.val$i are synthetic variables necessary to make > the local class work correctly): > > A$1B(A this$0, int val$i) { > super(); > this.this$0 = this$0; > this.val$i = val$i; > j = this.val$i; > } > > However, this is semantically incorrect, as setting the this$0 variable > after the superconstructor can cause spurious NullPointerExceptions. > > In their 1.4 release, Sun corrected their bug and now obey the JLS. > Therefore, compiling with -target 1.4 will issue a constructor like this > (although this is not valid Java, it is valid in the VM): > > A$1B(A this$0, int val$i) { > this.this$0 = this$0; > this.val$i = val$i; > super(); > j = this.val$i; > } > > There are several other changes in emitted code, conditional on the > -target flag. > > -- > This signature intentionally left boring. > > Eric Blake eb...@em... > BYU student, free software programmer > > ---- > To leave the Jikes-dev mailing list send a message to > Jik...@ww... with the word > unsubscribe in the body. For more subscription management: > http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jikes-dev |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-02-24 20:50:25
|
Archie Cobbs wrote: > FWIW, I think practically speaking you could modify SableVM to accept > classfiles with major version numbers up to 48 without any problems. I did this. We still have to fill a couple of call-back (JNI) hooks for Jikes 1.18 to work. Thanks for providing the Jikes info below. Etienne > > I asked on the jikes mailing list about their changes and what spec > they were reading from. Nobody could produce the spec, but I did get > some useful info (see below). > > -Archie > > __________________________________________________________________________ > Archie Cobbs * Packet Design * http://www.packetdesign.com > > >>From jik...@ww... Sat Feb 15 10:20:01 2003 >>From: Eric Blake <eb...@em...> >>Subject: Re: [Jikes-dev] New class file format >>To: jik...@ww... >>Message-ID: <3E4...@em...> >>MIME-Version: 1.0 >>Content-Type: text/plain; format=flowed; charset=us-ascii >>Content-Transfer-Encoding: 7bit >>Sender: jik...@ww... >>List-Archive: <http://www-124.ibm.com/pipermail/jikes-dev/> >>Date: Sat, 15 Feb 2003 11:18:01 -0700 >>Status: ORr >> >>Archie Cobbs wrote: >> >>>>So are you saying: the classfiles that jikes generates are exactly >>>>the same - except for the major/minor version number - no matter >>>>what -target flag is given? (If not, can you be specific about what >>>>the differences are?) Is this also true for Sun's javac? >>> >>>To answer my own question: it appears to me from looking at the source >>>that the only differences in the classfile is synthetic code generated >>>to handle "Foo.class", e.g., using exception chaining. >>> >>>So the -target flag (so far) only "targets" the version of the base >>>Java classes, rather than the virtual machine. >>> >>>Let me know if I've gotten myself confused :-) >> >>Read the source code in src/bytecode.cpp to see the different code >>sequences that jikes outputs depending on the -target option (search for >>control.option.target). For example, this code is different in 1.3 and 1.4: >> >>class A { >> void m(final int i) { >> class B { >> int j = i; >> } >> } >>} >> >>In 1.3, Sun's VM violated the JVMS, and didn't permit the initialization >>of instance variables before calling the superconstructor. Therefore, >>compiling with -target 1.3 will issue a constructor that looks like this >>(this.this$0 and this.val$i are synthetic variables necessary to make >>the local class work correctly): >> >>A$1B(A this$0, int val$i) { >> super(); >> this.this$0 = this$0; >> this.val$i = val$i; >> j = this.val$i; >>} >> >>However, this is semantically incorrect, as setting the this$0 variable >>after the superconstructor can cause spurious NullPointerExceptions. >> >>In their 1.4 release, Sun corrected their bug and now obey the JLS. >>Therefore, compiling with -target 1.4 will issue a constructor like this >>(although this is not valid Java, it is valid in the VM): >> >>A$1B(A this$0, int val$i) { >> this.this$0 = this$0; >> this.val$i = val$i; >> super(); >> j = this.val$i; >>} >> >>There are several other changes in emitted code, conditional on the >>-target flag. >> >>-- >>This signature intentionally left boring. >> >>Eric Blake eb...@em... >> BYU student, free software programmer >> >>---- >>To leave the Jikes-dev mailing list send a message to >>Jik...@ww... with the word >>unsubscribe in the body. For more subscription management: >>http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jikes-dev > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Sablevm-developer mailing list > Sab...@li... > https://lists.sourceforge.net/lists/listinfo/sablevm-developer > > . > -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Archie C. <ar...@de...> - 2003-02-24 21:47:52
|
Prof. Etienne M. Gagnon wrote: > > FWIW, I think practically speaking you could modify SableVM to accept > > classfiles with major version numbers up to 48 without any problems. > > I did this. We still have to fill a couple of call-back (JNI) hooks for > Jikes 1.18 to work. Also, in case anyone doesn't know, you can still use jikes 1.18 with SableVM. Just tell it to produce the older classfiles by using the -target command line option. E.g.: jikes -target 1.2 Foo.java -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-02-25 04:46:56
|
On Mon, Feb 24, 2003 at 01:35:19PM -0800, Archie Cobbs wrote:
> Also, in case anyone doesn't know, you can still use jikes 1.18
> with SableVM. Just tell it to produce the older classfiles by using
> the -target command line option.
>=20
> E.g.: jikes -target 1.2 Foo.java
This does not work for me, at least. I continue to get:
$ sablevm -Y SomeClass
*** Couldn't bind native method Java_java_lang_VMClassLoader_nativeCreateAr=
ray ***
*** or Java_java_lang_VMClassLoader_nativeCreateArray__Ljava_lang_String_2Z=
***
java.lang.NoClassDefFoundError: [Ljava.lang.ClassLoader;
at java.lang.ClassLoader.class$(ClassLoader.java:0)
at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:916)
at java.lang.ClassLoader.static{}(ClassLoader.java:155)
at java.lang.Class.step8(Class.java)
at java.lang.Class.initialize(Class.java:150)
at java.lang.VirtualMachine.main(VirtualMachine.java:78)
$
Etienne
--=20
Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
|
|
From: Archie C. <ar...@de...> - 2003-02-25 19:30:08
|
Prof. Etienne M. Gagnon wrote:
> > Also, in case anyone doesn't know, you can still use jikes 1.18
> > with SableVM. Just tell it to produce the older classfiles by using
> > the -target command line option.
> >
> > E.g.: jikes -target 1.2 Foo.java
>
> This does not work for me, at least. I continue to get:
>
> $ sablevm -Y SomeClass
> *** Couldn't bind native method Java_java_lang_VMClassLoader_nativeCreateArray ***
> *** or Java_java_lang_VMClassLoader_nativeCreateArray__Ljava_lang_String_2Z ***
> java.lang.NoClassDefFoundError: [Ljava.lang.ClassLoader;
> at java.lang.ClassLoader.class$(ClassLoader.java:0)
> at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:916)
> at java.lang.ClassLoader.static{}(ClassLoader.java:155)
> at java.lang.Class.step8(Class.java)
> at java.lang.Class.initialize(Class.java:150)
> at java.lang.VirtualMachine.main(VirtualMachine.java:78)
Interesting...
Well, admittedly I didn't actually try this.. so I guess SableVM must
implement a few more native methods before this can work... it's not
clear whether this is a bug in the jikes -target flag, or just jikes
triggering an "unimplemented feature" bug in SableVM.
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X