sablevm-developer Mailing List for SableVM (Page 49)
Brought to you by:
egagnon
Menu
▾
▴
sablevm-developer — SableVM developer mailing list
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: David <db...@cs...> - 2003-02-24 18:28:55
|
On Mon, Feb 24, 2003 at 01:22:57AM -0500, Chris Pickett wrote: > Small task, but then again small tasks are easily accomplished. Merge=20 > the functionality of all the build scripts floating around (mine,=20 > Bruno's, Etienne's, and Grzegorz's) and the two in the CVS into one=20 > script. I'd vote for Bruno's script as the basis since it's really eas= y=20 > to read and understand (and therefore maintain), and I'd vote for Bruno= =20 > to do the job (unless he no longer wants to). I don't think the scripts necessarily have to be merged. We need a simple to use script in the distribution root directory to simply install sablevm for end-users. Goal: Easy and error-free installation. All the developper scripts should go in some other directory (say contrib/). David >=20 > Ciao-ciao, > Chris >=20 > Prof. Etienne M. Gagnon wrote: >=20 > >Hi again, > > > >I,d like to start drafting a list of tasks to be done in SableVM, > >along with priorities. > > > >Please contribute any suggestion for improving the following list: > > > >In descending priority: > > > >- Get SableVM to run with latest Jikes. > > > >- Update to latest GNU Classpath CVS snapshot. > > > >- Merge all SableVM-specific changes into official GNU Classpath CVS > > (along with proposal to use m4 preprocessor for managing VM-specific > > library code). > > > >- Improve abstraction layer for specifying inlinability of bytecode > > implementations. > > > >- Include a regression suite (like Mauve), and automate daily checks > > for failures in CVS snapshot. > > > > > >Anything else? Different priorities? Your opinion is important. > > > >Have fun! > > > >Etienne > > > > > >=20 > > >=20 >=20 >=20 > ------------------------------------------------------- > 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 --=20 --- David B=E9langer Graduate Student School of Computer Science McGill University Office: MC226 Web page: http://www.cs.mcgill.ca/~dbelan2/ Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt |
|
From: Bruno D. <bru...@ma...> - 2003-02-24 14:22:41
|
Hi, When I started to write my version of the script, I wanted a simple=20 replacement for build/build-many which would check for errors during the=20 builds. You may disagree with the way I do it (I don't think it is a grea= t=20 script either, but it was written very late too). I specifically chose to= =20 only allow predefined configurations. I think I made it rather easy to ad= d=20 new configurations, but the main point was to let a user compile sablevm=20 easily. Not all users will be developers, and most of them propably don't= =20 know a lot about the different configurations. I suspect that most users,= =20 given the choice, will opt for the fastest version of sablevm, not even=20 bothering to look at what makes it faster. I think my script is not all a= ll=20 what sablevm-developers want to have, but again this was not the goal.=20 Grzegorz's script is much better for that. Anyway, I have no objection to merging both scripts, although I think tha= t we=20 could have one version (closer in spirit to what I have done) in the=20 "official" sablevm package and one (closer to Grzegorz's) in the CVS. Thi= s=20 way, developers would have what they want, and sablevm users too. Cheers, Bruno On February 24, 2003 07:26 am, Chris Pickett wrote: > you guys can work something > out. =A0I think the various sablevm builds should not be built into the > script itself, but only the different options passable to configure (it > would be nice to see one letter abbreviations though, like SDIGTB for > switch, direct, inlined, GC, traditional, bidirectional). =A0 Rather, t= he > user can invoke the script specifying how many different builds and wit= h > what options. =A0If they like, this can go in a secondary script. =A0Th= e > main purpose is to simplify the autoconf routine, as well as handling > CVS and .tar.gz distributions. =A0I don't know, I'm rambling. > > Cheers, > Chris |
|
From: Chris P. <chr...@ma...> - 2003-02-24 12:26:06
|
> >compiling sablevm in different ways. > >The very serious question is whether my approach of "swiss-army-knife" >is right (Chris says that Bruno's script is easier to read, so there's >probably sth. wrong with mine). > I wouldn't necessarily listen to me as I don't know enough about scripts to write either yours or Bruno's. I'm sure you guys can work something out. I think the various sablevm builds should not be built into the script itself, but only the different options passable to configure (it would be nice to see one letter abbreviations though, like SDIGTB for switch, direct, inlined, GC, traditional, bidirectional). Rather, the user can invoke the script specifying how many different builds and with what options. If they like, this can go in a secondary script. The main purpose is to simplify the autoconf routine, as well as handling CVS and .tar.gz distributions. I don't know, I'm rambling. Cheers, Chris |
|
From: Grzegorz B. P. <ga...@de...> - 2003-02-24 11:29:28
|
W li=B6cie z pon, 24-02-2003, godz. 06:19, Prof. Etienne M. Gagnon pisze:=20 > Hi again, >=20 > I,d like to start drafting a list of tasks to be done in SableVM, > along with priorities. >=20 > Please contribute any suggestion for improving the following list: >=20 > In descending priority: >=20 > - Get SableVM to run with latest Jikes. >=20 > - Update to latest GNU Classpath CVS snapshot. (*) > - Merge all SableVM-specific changes into official GNU Classpath CVS > (along with proposal to use m4 preprocessor for managing VM-specific > library code). - Get the GTK-peers working (so far kissme seems to be best here) It could be probably even at (*) position after merge w/ latest classpath. > - Improve abstraction layer for specifying inlinability of bytecode > implementations. Hmm... did you have to make some arch-specific changes there? =46rom what I understood - as long as we keep using GCC - we shouldn't see much problems here. Or maybe you think of speeding things up on some arches where GCC produces better inlinable code? > - Include a regression suite (like Mauve), and automate daily checks > for failures in CVS snapshot. > Anything else? Different priorities? Your opinion is important. I also would like to see some one-for-all build script.=20 I am considering to either contribute to Bruno's script (but that would require not only some improvements but also changes as I don't agree on some of the ways it does things) or to extend my script (which, keep in mind, has been written for pure fun between 0am and 3am in the late night/morning) to be seriously usable. The main lack I see in mine script are the missing options for compiling sablevm in different ways. The very serious question is whether my approach of "swiss-army-knife" is right (Chris says that Bruno's script is easier to read, so there's probably sth. wrong with mine). Cheers, Grzegorz B. Prokopski --=20 Grzegorz B. Prokopski <ga...@de...> Debian http://www.debian.org/ |
|
From: Grzegorz B. P. <ga...@de...> - 2003-02-24 11:01:35
|
W li=B6cie z pon, 24-02-2003, godz. 05:52, Prof. Etienne M. Gagnon pisze:=20 > Hi all. >=20 > So, the problem was that, by default, malloc()ed memory does not have > execution permission. (Grzegorz: I guess the same applies to Sparc). > The solution is a very few lines of code in prepare_code.c. (Search > for __ia64__). That's great news! I will upload new debian packages with ia64-inlined-engine patch and sparc-non-inlined shortly. GBP --=20 Grzegorz B. Prokopski <ga...@de...> Debian http://www.debian.org/ |
|
From: Chris P. <chr...@ma...> - 2003-02-24 06:22:45
|
Small task, but then again small tasks are easily accomplished. Merge the functionality of all the build scripts floating around (mine, Bruno's, Etienne's, and Grzegorz's) and the two in the CVS into one script. I'd vote for Bruno's script as the basis since it's really easy to read and understand (and therefore maintain), and I'd vote for Bruno to do the job (unless he no longer wants to). Ciao-ciao, Chris Prof. Etienne M. Gagnon wrote: >Hi again, > >I,d like to start drafting a list of tasks to be done in SableVM, >along with priorities. > >Please contribute any suggestion for improving the following list: > >In descending priority: > >- Get SableVM to run with latest Jikes. > >- Update to latest GNU Classpath CVS snapshot. > >- Merge all SableVM-specific changes into official GNU Classpath CVS > (along with proposal to use m4 preprocessor for managing VM-specific > library code). > >- Improve abstraction layer for specifying inlinability of bytecode > implementations. > >- Include a regression suite (like Mauve), and automate daily checks > for failures in CVS snapshot. > > >Anything else? Different priorities? Your opinion is important. > >Have fun! > >Etienne > > > > |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-02-24 05:23:16
|
Hi again, I,d like to start drafting a list of tasks to be done in SableVM, along with priorities. Please contribute any suggestion for improving the following list: In descending priority: - Get SableVM to run with latest Jikes. - Update to latest GNU Classpath CVS snapshot. - Merge all SableVM-specific changes into official GNU Classpath CVS (along with proposal to use m4 preprocessor for managing VM-specific library code). - Improve abstraction layer for specifying inlinability of bytecode implementations. - Include a regression suite (like Mauve), and automate daily checks for failures in CVS snapshot. Anything else? Different priorities? Your opinion is important. Have fun! Etienne --=20 Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-02-24 05:13:27
|
Hi there. I'd like to start applying patches that have previously been posted to this mailing-list. If you any any pending patch which is NOT already included as an attachment to a bug report, please do one of the following: 1 - submit a bug report with the patch as attachment, or 2 - resend a message to this list with the patch as attachment. Thanks, Etienne --=20 Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-02-24 05:04:21
|
Hi all. So, the problem was that, by default, malloc()ed memory does not have execution permission. (Grzegorz: I guess the same applies to Sparc). The solution is a very few lines of code in prepare_code.c. (Search for __ia64__). Have fun! 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-24 00:30:35
|
Hi! Nothing big today, another arch added to the bunch of already supported. Let me say that IMHO sparc is very strange arch or rather... mismatched one. The kernel is 64bit, userpace is 32bit and when I was trying to use somewhat newer set of assembler instructions - I was getting errors claiming that I am compiling for the oldest architecture (sth. like 386 in x86 world) and I don't have right to use newer instructions. So for now, utils someone more knowledgable comes - the instruction used are the simplest ones. Anyway - as we (with Etienne) learned lately - there are even more... strange arches, like ia64 which seems to be quite tricky to make the inlined engine work... Work is in progress though. Getting back to the point - the patch is simple and is attached. Have a nice day Grzegorz B. Prokopski -- Grzegorz B. Prokopski <ga...@de...> Debian http://www.debian.org/ |
|
From: Grzegorz B. P. <ga...@de...> - 2003-02-22 21:03:21
|
I already have all needed tools to start playing w/ sparc, however today I am still figting w/ ia64. The error occurs at instructions_preparation_inlined_threaded.c:17548 which is: goto *((pc++)->implementation); It happens on first try. Not sure yet why and how to track it. I spent some time looking (debugging) a bit closer at=20 _svmf_prepare_code, but haven't found anything unusual. The code for CPU to exectue seems to be created. (gdb) print (char*)pc->implementation $29 =3D 0x6000000000022800 "\v\220=E0K?# \001H " (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0x6000000000022800 in ?? () It's strange that it fails on EXACTLY the same address as the called one. I mean - it fails immediately!=20 I think that there are following possibilities: - the memory at the address has not been allocated - the first assembler instruction is not recognized by CPU - the memory page we have written the data to - is not executable I think we could elimiate some of the above cases to learn which one is true. The last option is the strangest, but IMO not impossible. Still working on it GBP PS: Etienne - if you had time and an idea how to help me - I am on IRC for maximum 2 hours from now now on - tonight, or tomorrow since about 4pm my local time. --=20 Grzegorz B. Prokopski <ga...@de...> Debian http://www.debian.org/ |
|
From: Grzegorz P. <gr...@se...> - 2003-02-22 20:05:18
|
In src/libsablevm.system.h is being used svmt_f64 type which is not defined anywhere. I belive that there should be svmt_d64 used instead. W/o this fix SableVM doesn't build on 64bit platforms. GBP -- Grzegorz Prokopski <gr...@se...> |
|
From: Grzegorz B. P. <ga...@de...> - 2003-02-21 23:10:21
|
Hi! I have just uploaded debian packages of SableVM 1.0.6 JVM. (you can find them at http://incoming.debian.org or later - in ftp.debian.org/debian repositories) These packages bring a number of improvements, mainly: - improvements in reflection code (ANT works now!) - added /usr/lib/jni to default JNI search path - it is also possible to run gjdoc (see below notes) - supported arches now also include PPC and Alpha, both using the fastest inlined-threaded engine (ia64 is still using slower engine, but it's mysterious problems are being actively worked on) Thanks to ANT support - it is now possible to use free-java-sdk to compile java programs using ANT as their build engine. Unfortunatelly jikes > 1.15 is still not supported Please install jikes from stable distribution I recompiled gjdoc w/ jikes 1.15 and I think is ran, but I am not javadoc expert. I would appreciate if someone could test it. BTW: current gjdoc packages as they come from maintainer - are only able to use kaffe. If it were proven that gjdoc works w/ SableVM - we could probably prepare gjdoc to support this alternative. Please drop me a note if the packages work for you (or not). Happy testing, Grzegorz B. Prokopski --=20 Grzegorz B. Prokopski <ga...@de...> Debian http://www.debian.org/ |
|
From: Bruno D. <bru...@ma...> - 2003-02-21 02:46:14
|
Hi, I just noticed a slightly annoying thing with the latest SableVM release. If you run a 'make distclean' in the sablevm-1.0.6 directory, then you won't be able to compile the direct threaded interpreter anyore, because of a missing 'instructions_preparation_direct_threaded.c'. It seems to me that sablevm-1.0.6/src/libsablevm/Makefile.in only includes a dependency to instructions_preparation_inline_threaded.c, which causes the other ones (direct and switch) to never be regenerated. To test the hypothesis, I ran the aclocal ... automake sequence, and it fixed the problem. Cheers, -- Bruno Dufour Sable Research Group McGill University, Montreal, Canada bru...@ma... |
|
From: Grzegorz B. P. <ga...@de...> - 2003-02-21 02:29:47
|
Hi!
I thought that it could be cool to join the new sport that appears to
be born on this list - creating new build scripts for SableVM.
So I sat down and wrote a completly new script.......
I encourage you to download it and try yourself, but to make it easier
for you to get interested in it - here's the output of 'help' command:
Usage: script operation [package|...] [option|...]
Operations:
help - this help screen
unpack - unpack source(s) from current directory
build - clean, configure and build specified packages
install - install specified packages
autoinstall - if needed: unpack and regenerate, then build and install
uninstall - uninstall specified packages
regenerate - do the aclocal, libtoolize, autoconf and auto* dance
indent - indent sources in specified packages
ctags - create ctags for specified packages
Packages:
sablevm - sablevm-$VERSION[.tar.gz]
native - sablevm-native-library-$VERSION[.tar.gz]
classes - sablevm-class-library-$VERSION[.tar.gz]
all - all of the above
Options:
version=x.y.z - operate on specified version [default=auto]
dest=/abc/xyz - install in specified directory
[default=`pwd`/root/usr/local]
debug - 'build' with debugging features enabled [default w/o]
scriptdbg - output debug information while running this script
cvsmode - we act a bit differently when using CVS repositories
Some things don't work yet, like: autoinstall, uninstall, indent, ctags
and cvsmode, but it shouldn't be hard to add them.
The script also has some nice features, like remembering last options
and packages on which the operation is to be done. So you can do:
script unpack all version=1.0.6 dest=./root/usr/local debug
and then you can simply do:
script build
script install
and it will know what to do based of parameters given previously.
I'd like to hear from you what you think and in case you were interested
in using it - I am open for any suggestions and your help :-)
Cheers,
Grzegorz B. Prokopski
--
Grzegorz B. Prokopski <ga...@de...>
Debian http://www.debian.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: Bruno D. <bru...@ma...> - 2003-02-20 05:26:25
|
On Thursday 20 February 2003 05:01 am, Prof. Etienne M. Gagnon wrote:
> On Wed, Feb 19, 2003 at 11:23:31PM -0500, Chris Pickett wrote:
> > Okay, I looked at your solution, but apart from the goto end:, it
> > doesn't seem different from the fix I suggested a couple of hours ago
> > (ignoring the JNI_OK stuff):
> >...
> > is there really a big difference? or are you mainly talking about the
> > comment?
>
> It seems I have read your code a little too quickly; I thought you
> were calling _svmf_abort(or fatal_error?) [this is why I was talking
> about aborting]. It's probably because it is late, and because
> without the goto end I assumed the call didn't return (which is what
> _svmm_fatal_error() does).
>
> The "goto end" is important for maintenance. Imagine somebody
> modifies the code:
>
> if (sched_yield() != 0)
> _svmf_error_InternalError (env);
>
> yield_done = JNI_TRUE;
>
> ...
>
>
> This would be wrong, whereas:
>
> if (sched_yield() != 0)
> {
> _svmf_error_InternalError (env);
> goto end;
> }
>
> yield_done = JNI_TRUE;
>
> end:
> ...
>
> does the intended thing.
>
> > P.S. Can you get the JNI book online? I have the JVM spec as part of
> > the Java docs, but I take it this is something else.
>
> Not really. Only the specification part is online (with a few errors,
> though), but the user guide part is not. Prof. Hendren should have a
> copy of it somewhere.
Not quite true. Visit
http://java.sun.com/docs/books/jni/index.html
It seems like the entire book is there.
(or http://java.sun.com/docs/books/index.html in general website for entire
series)
Bruno
>
> Etienne
|
|
From: Prof. E. M. G. <eti...@uq...> - 2003-02-20 05:07:21
|
On Wed, Feb 19, 2003 at 11:23:31PM -0500, Chris Pickett wrote:
> Okay, I looked at your solution, but apart from the goto end:, it=20
> doesn't seem different from the fix I suggested a couple of hours ago=20
> (ignoring the JNI_OK stuff):
>...=20
> is there really a big difference? or are you mainly talking about the=20
> comment?
It seems I have read your code a little too quickly; I thought you
were calling _svmf_abort(or fatal_error?) [this is why I was talking
about aborting]. It's probably because it is late, and because
without the goto end I assumed the call didn't return (which is what
_svmm_fatal_error() does).
The "goto end" is important for maintenance. Imagine somebody
modifies the code:
if (sched_yield() !=3D 0)
_svmf_error_InternalError (env);
yield_done =3D JNI_TRUE;
=2E..
This would be wrong, whereas:
if (sched_yield() !=3D 0) =
=
=20
{
_svmf_error_InternalError (env); =
=
=20
goto end;
}
yield_done =3D JNI_TRUE; =
=
=20
end:
=2E..
does the intended thing.
> P.S. Can you get the JNI book online? I have the JVM spec as part of=20
> the Java docs, but I take it this is something else.
Not really. Only the specification part is online (with a few errors,
though), but the user guide part is not. Prof. Hendren should have a
copy of it somewhere.
Etienne
--=20
Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
|
|
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: Chris P. <chr...@ma...> - 2003-02-20 04:23:22
|
>
>
>If you look at my solution, you'll note that I suggest that we might
>simply ignore the return value anyway. This is why your original code
>semmed OK to me (I was assuming you had already investigated about
>return values & POSIX compliance).
>
>
Okay, I looked at your solution, but apart from the goto end:, it
doesn't seem different from the fix I suggested a couple of hours ago
(ignoring the JNI_OK stuff):
if (sched_yield() != 0)
_svmf_error_InternalError (env);
whereas you have:
*if* (sched_yield () != 0)
{
//* Should we really really throw an error on failure? Maybe we
could simply ignore the return value, if no harm is implied.
Suggestions are welcome. Etienne *//
_svmf_error_InternalError (env);
*goto* *end*;
}
*end*:
................
is there really a big difference? or are you mainly talking about the
comment?
Cheers,
Chris
P.S. Can you get the JNI book online? I have the JVM spec as part of
the Java docs, but I take it this is something else.
|
|
From: Prof. E. M. G. <eti...@uq...> - 2003-02-20 04:03:43
|
On Wed, Feb 19, 2003 at 10:24:44PM -0500, Chris Pickett wrote: > Well it's used all over the place in your code and I thought it would=20 > help me to understand it better. The reason I included it in that=20 > function was because there are many other uses of JNI_OK in=20 > java_lang_Thread.c. OK. > Bruno just answered my question, so it's probably a good idea if I look= =20 > at jni.h a bit. You should read the JNI specification book. It is very well written. It has a first part that explains how to use the JNI interface from a programmer's perspective (giving much insight on the reason why things are setup that way), and the second part is the specification itself. This is where JNI_OK is really defined. The JNI interface has had a very deep impact on the architecture of SableVM. This is why I think you should read the document (in addition to reading the JVM specification, of course). jni.h encodes what is specified in the JNI book. > Okay, sched.h conforms to POSIX.1b, but it's still the GNU C library, so= =20 > if you don't want dependence on sched.h then use pthread_yield(). They= =20 > do the same thing . . . The GNU C library (commonly called glibc or libc6) implements the standard C library + POSIX + other things + GNU extentions. You simply have to restrict yourself to using Standard C + POSIX compatible calls. =2E.. > And so I figured it was a pretty bad thing if the yield() didn't work=20 > because it says pathological, so I thought killing the VM was reasonable. If you look at my solution, you'll note that I suggest that we might simply ignore the return value anyway. This is why your original code semmed OK to me (I was assuming you had already investigated about return values & POSIX compliance). Have fun. Etienne --=20 Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Chris P. <chr...@ma...> - 2003-02-20 03:24:43
|
Prof. Etienne M. Gagnon wrote: >On Wed, Feb 19, 2003 at 09:35:54PM -0500, Chris Pickett wrote: > > >>Okay. Where is JNI_OK defined? >> >> > >My first question would be: why do you need this information? > > Well it's used all over the place in your code and I thought it would help me to understand it better. The reason I included it in that function was because there are many other uses of JNI_OK in java_lang_Thread.c. Bruno just answered my question, so it's probably a good idea if I look at jni.h a bit. > > >>Well, actually, I realized last night about checking the error status, >>after I emailed you to say that I would send a patch today, but then >>today you had already committed the code. Then I got caught up in >>making scripts, and didn't get around to telling you yet. >> >>sched_yield() returns 0 if there was no problem, or -1 if there was an >>error. >> >>sched_yield() is not necessarily posix compliant, so perhaps you'd >>better use pthread_yield() ... pthread_yield() doesn't return a value >>ever either, so just replace sched_yield() with pthread_yield() and >>forget about the error check. >> >> > > >My documentation says: > >$ man sched_yield >... >CONFORMING TO > POSIX.1b (formerly POSIX.4) >... > > Okay, sched.h conforms to POSIX.1b, but it's still the GNU C library, so if you don't want dependence on sched.h then use pthread_yield(). They do the same thing . . . > >Also, aborting the VM if this call fails is quite dramatic! The VM >should only be aborted if you have detected an error in the VM itself, >or if something REALLY bad happened (e.g. memory corruption). > Well, the sched_yield() documentation at http://www.gnu.org/manual/glibc-2.2.5/html_node/Basic-Scheduling-Functions.html says: int *sched_yield*/ (void) / Function This function voluntarily gives up the process' claim on the CPU. Technically, |sched_yield| causes the calling process to be made immediately ready to run (as opposed to running, which is what it was before). This means that if it has absolute priority higher than 0, it gets pushed onto the tail of the queue of processes that share its absolute priority and are ready to run, and it will run again when its turn next arrives. If its absolute priority is 0, it is more complicated, but still has the effect of yielding the CPU to other processes. If there are no other processes that share the calling process' absolute priority, this function doesn't have any effect. To the extent that the containing program is oblivious to what other processes in the system are doing and how fast it executes, this function appears as a no-op. The return value is |0| on success and in the pathological case that it fails, the return value is |-1| and |errno| is set accordingly. There is nothing specific that can go wrong with this function, so there are no specific |errno| values. ============== And so I figured it was a pretty bad thing if the yield() didn't work because it says pathological, so I thought killing the VM was reasonable. Again, I was just copying what you did elsewhere in the file. > >Otherwize, you throw either an "expected" exception (if appropriate), >or you throw Error otherwise, as specified in the Java+JVM >specifications. > >OK. Next time you'll be more careful and ask questions if you are >unsure. ;-) > >I encourage you to look at my fix to your code, once I check-it in >CVS. > I will. For now, you should probably check every line of code that I submit ... it's not so uncommon to have reviewers and even super-reviewers (for large projects). However, everything's under revision control anyway so no matter what happens to the source tree it will never be the end of the world. Cheers, Chris |
|
From: Bruno D. <bru...@ma...> - 2003-02-20 03:10:31
|
Hi Chris, Etienne is right. You do not need to know where JNI_OK is defined. Unless you want to modify the value (and you don't want to that, of course), you should not care. But to satisfy your curiosity, look at src/libsablevm/include/jni.h. This is the standard place to define it, BTW. You should have been able to find that easily using grep. Cheers, Bruno On Thursday 20 February 2003 02:35 am, Chris Pickett wrote: > Hi Etienne, > > Prof. Etienne M. Gagnon wrote: > >On Wed, Feb 19, 2003 at 08:36:58PM -0500, Chris Pickett wrote: > >>I don't know what JNI_OK is defined to be (I couldn't find it with > >>grep), but if it's zero then that's: > >> > >>if (sched_yield() != JNI_OK) > >> _svmf_error_InternalError (env); > > > >No!!!! JNI_OK is used by _svmf_* functions to indicate success. You > >should never make any relation between the actual integer value JNI_OK > >is defined as, and the accidental value it matches in another context! > > > > > >If I decided to change JNI_OK to be defined as 36, the code above > >would start misbehaving (assuming JNI_OK was originally defined as > >zero). > > Okay. Where is JNI_OK defined? > > >Also, you should *ALWAYS* check return values of non-void functions. > >I had not double-checked if sched_yield returned a value. I guess I > >should never trust submitted code and review thoroughly every line of > >code and the documentation of every called library function... > > Well, actually, I realized last night about checking the error status, > after I emailed you to say that I would send a patch today, but then > today you had already committed the code. Then I got caught up in > making scripts, and didn't get around to telling you yet. > > sched_yield() returns 0 if there was no problem, or -1 if there was an > error. > > sched_yield() is not necessarily posix compliant, so perhaps you'd > better use pthread_yield() ... pthread_yield() doesn't return a value > ever either, so just replace sched_yield() with pthread_yield() and > forget about the error check. > > sched_yield() is in sched.h which is in the GNU C library, whereas > pthread_yield() is in pthreads. The only reason I used sched_yield() > was because that's what you and Clark and I talked about. > > Sorry for not letting you know earlier and not checking the code I sent > you. Transgression #1. > > Chris |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-02-20 03:01:17
|
On Wed, Feb 19, 2003 at 09:35:54PM -0500, Chris Pickett wrote:
> Okay. Where is JNI_OK defined?
My first question would be: why do you need this information?
> Well, actually, I realized last night about checking the error status,=20
> after I emailed you to say that I would send a patch today, but then=20
> today you had already committed the code. Then I got caught up in=20
> making scripts, and didn't get around to telling you yet.
>=20
> sched_yield() returns 0 if there was no problem, or -1 if there was an=20
> error.
>=20
> sched_yield() is not necessarily posix compliant, so perhaps you'd=20
> better use pthread_yield() ... pthread_yield() doesn't return a value=20
> ever either, so just replace sched_yield() with pthread_yield() and=20
> forget about the error check.
My documentation says:
$ man sched_yield
=2E..
CONFORMING TO
POSIX.1b (formerly POSIX.4)
=2E..
Also, aborting the VM if this call fails is quite dramatic! The VM
should only be aborted if you have detected an error in the VM itself,
or if something REALLY bad happened (e.g. memory corruption).
Otherwize, you throw either an "expected" exception (if appropriate),
or you throw Error otherwise, as specified in the Java+JVM
specifications.
OK. Next time you'll be more careful and ask questions if you are
unsure. ;-)
I encourage you to look at my fix to your code, once I check-it in
CVS.
Etienne
--=20
Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
|
|
From: Chris P. <chr...@ma...> - 2003-02-20 02:35:44
|
Hi Etienne, Prof. Etienne M. Gagnon wrote: >On Wed, Feb 19, 2003 at 08:36:58PM -0500, Chris Pickett wrote: > > >>I don't know what JNI_OK is defined to be (I couldn't find it with >>grep), but if it's zero then that's: >> >>if (sched_yield() != JNI_OK) >> _svmf_error_InternalError (env); >> >> > >No!!!! JNI_OK is used by _svmf_* functions to indicate success. You >should never make any relation between the actual integer value JNI_OK >is defined as, and the accidental value it matches in another context! > > >If I decided to change JNI_OK to be defined as 36, the code above >would start misbehaving (assuming JNI_OK was originally defined as >zero). > Okay. Where is JNI_OK defined? > >Also, you should *ALWAYS* check return values of non-void functions. >I had not double-checked if sched_yield returned a value. I guess I >should never trust submitted code and review thoroughly every line of >code and the documentation of every called library function... > > Well, actually, I realized last night about checking the error status, after I emailed you to say that I would send a patch today, but then today you had already committed the code. Then I got caught up in making scripts, and didn't get around to telling you yet. sched_yield() returns 0 if there was no problem, or -1 if there was an error. sched_yield() is not necessarily posix compliant, so perhaps you'd better use pthread_yield() ... pthread_yield() doesn't return a value ever either, so just replace sched_yield() with pthread_yield() and forget about the error check. sched_yield() is in sched.h which is in the GNU C library, whereas pthread_yield() is in pthreads. The only reason I used sched_yield() was because that's what you and Clark and I talked about. Sorry for not letting you know earlier and not checking the code I sent you. Transgression #1. Chris |
6 messages has been excluded from this view by a project administrator.
