sablevm-developer Mailing List for SableVM (Page 45)
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: Prof. E. M. G. <eti...@uq...> - 2003-04-01 00:45:23
|
Chris Pickett wrote: >> - All registered developers have write access to >> - sablevm-experimental (trunk only) >> - sablevm/doc (trunk only) > If it's not too late, It's never too late. :-) > I think there should be an experimental doc and a > stable doc. It could be bad if someone checked out the stable > distribution and got bad docs ... plus this means all docs get reviewed > before going into stable. I agree with you. On the short term I will let you access the stable doc directory so that you can check-in your document updated to reflect my answers in the thread http://sourceforge.net/mailarchive/forum.php?thread_id=1834524&forum_id=4154 . I have also granted write access to David, so that he can checkin any important fix in the stable tree when I am away. Thanks! Etienne -- 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-04-01 00:18:45
|
Hi, Sorry for not being in touch lately. Prof. Etienne M. Gagnon wrote: >Hi All, > >Today, I have added a sablevm-experimental module on CVS and activated >commit controls in CVS as follows: > >- All registered developers have write access to > - sablevm-experimental (trunk only) > - sablevm/doc (trunk only) > > If it's not too late, I think there should be an experimental doc and a stable doc. It could be bad if someone checked out the stable distribution and got bad docs ... plus this means all docs get reviewed before going into stable. Other than that, I think what you've laid out is fine (I mean, any changes made to your plan will be minor and it's difficult to evaluate at this point whether they would be good or bad, so what' the point in making them). However, I do think the doc thing is kind of important. Don't know what others think about this. Chris >sablevm-experimental has a vendor branch containing an image of the >latest sablevm module trunk, that I will regularly update. > >I have set up the repository this way in prevision of the following >development model: > >1- The sablevm module should always be in a "releasable" state. Write >access to it is highly restricted (temporary or permanent write access >negotiable on a developer basis). > >2- The sablevm-experimental module should be kept, as much as >possible, in a relatively stable state. When you checkin your >"special enhancements" (e.g. JIT, speculative code, whatever), you >should hide them within C #ifdef conditionals (with an appropriate >entry in configure.ac). You can also put some personal >code/documentation in sablevm-experimental/developer/your-username ** >if and only if ** it is licensed under SableVM's license, as usual. > >3- 2 ways for testing your stuff: > a) checkout sablevm, apply you changes, test them, use > "cvs diff -u -N" to get unified diffs to submit in the tracker. > b) checkout sablevm-experimental, apply your changes, checkin your > changes, ask other developers to test. Go back to a) for > preparing a patch. > >To be decided: Where do we put the experimental class/native >libraries? I was thinking of putting them in subdirectories of >sablevm-experimental. What do you think? > >Any comment on this development model? > >Etienne > > |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-03-31 23:23:06
|
Hi all! Have I told you before that I dislike CVS? Restoring pre-merge state turned out to be quite an adventure, even though I was only using trunk and vendor branches. I won't say more; I'll let you have fun with sablevm-experimental, which also uses a vendor and a trunk. ;-) OK, so to summarize: a) sablevm-experimental (trunk) + subdirs == includes code from latest Classpath CVS; that is where our help is required. :-) b) sablevm (trunk) + sablepath-classes (trunk) + sablepath-libs (trunk) == release 1.0.8 + *stable* modifications c) sablepath-* (vendor) = Classpath Snapshot + indentation + directory reorganization; useful as a reference, or for "cvs [r]diff -u". Happy hacking! Etienne -- 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-03-31 19:11:07
|
David B=E9langer wrote:
>>>To be decided: Where do we put the experimental class/native
>>>libraries? I was thinking of putting them in subdirectories of
>>>sablevm-experimental. What do you think?
> I'm using a similar directory structure locally and it works fine with
> me.
OK. So, I'll do the following (unless somebody voices an objection withi=
n the=20
upcoming minutes):
1) I will add 2 subdirectories under sablevm-experimental:
- sablevm-native-library:
Contains the broken merged sablepath-libs & latest CVS snapshot.
- sablevm-class-library
Contains the broken merged sablepath-classes & latest CVS snapsho=
t.
2) I will bring back the HEAD of sablepath-classes & sablepath-libs to th=
eir=20
unbroken "before merge" state by applying a reverse patch. The idea is t=
o keep=20
the "stable" directories in releasable state at all times. (I had to=20
temporarily break this due to the vendor-branch CVS update).
3) For the convenience of developers, I will put files which include the =
differences between the broken merged state and [a) 1.0.8 and b) Classpat=
h=20
snapshot]. I will put these "diff-to-*" files in the root of=20
sablevm-experimental/sablevm-*-library/ .
You can also obtain these yourself using "cvs diff -N -u".
> Yes, I could give some help on this. However in the next few days I
> want to put most of my time on the JIT as I am getting closer to
> something that runs.
Thanks.
I will myself have little time in the upcoming two weeks to work on Sable=
VM, as=20
I have presentations, courses, meetings, and travel to conference to do &=
=20
prepare. So, everybody should feel free to help fix problems in=20
sablevm-experimental without further notice.
Also, I got no feedback about the proposed development model. Do this me=
ans=20
that 1) it is too rigid; we should simply give full access to everyone, o=
r 2) it=20
is just fine??? I am quite willing to make adjustments, if necessary.
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: David <db...@cs...> - 2003-03-31 18:32:07
|
On Sun, Mar 30, 2003 at 06:21:12PM -0500, Prof. Etienne M. Gagnon wrote: > Hi All. >=20 > I have started the process of updating sablepath-classes & sablepath-li= bs=20 > to the latest GNU Classpath CVS image. >=20 > This will most probably BREAK sablevm. I will need help to test SableV= M=20 > and fix any bugs this update has introduced. >=20 > To help working on this, it would be best if people made suggestions on= the=20 > CVS repository organization. One important question I have already rai= sed,=20 > and that we should address quickly [a manager would say: yesterdday! ;-= )]=20 > is: >=20 > >To be decided: Where do we put the experimental class/native > >libraries? I was thinking of putting them in subdirectories of > >sablevm-experimental. What do you think? I'm using a similar directory structure locally and it works fine with me. >=20 > The objective is to get rid of sablepath-libs & sablepath-classes as so= on=20 > as possible, making sure SableVM users can directly use GNU Classpath,=20 > instead. But, this will require merging our local changes into Classpat= h=20 > CVS. Before we can do that, we have to make sure that "current Classpa= th=20 > CVS + local SableVM-specific changes =3D working SableVM". >=20 > Please let me know your opinion about the sablepath-* vs=20 > sablevm-experimental question. Also, If you are willing to help with t= he=20 > sablepath update, just say so. :-) Yes, I could give some help on this. However in the next few days I want to put most of my time on the JIT as I am getting closer to something that runs. David >=20 > Thanks a lot in advance! >=20 > Etienne >=20 > --=20 > Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ > SableVM: http://www.sablevm.org/ > SableCC: http://www.sablecc.org/ >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > 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: Chris P. <chr...@ma...> - 2003-03-31 16:59:13
|
Prof. Etienne M. Gagnon wrote: > Archie Cobbs wrote: > >> Presumably you could have simplified things by just waiting for all >> threads to stop (instead of just waiting for non-JNI threads) before >> GC'ing, but then you might have to wait an arbitrarily long time, >> because a JNI thread could be doing something slow, sleeping, etc. > > > 1) Non-JNI threads have at least one GC check point per loop iteration > (this is a simplification of the reality which includes method entry, > etc.) > 2) Nothing prevents a JNI thread to go into a infinite loop, or not to > call-back the VM, or to sleep indefinitely. > > So, it is reasonable to assume a non-JNI thread will soon reach a GC > point, and it would be an error to wait for JNI threads to return or > call back the VM before proceeding with GC. > > In fact, if you read the JNI spec carefully, you'll notice how direct > access to a reference is never given to native code. You may > rightfully deduce that this was made specifically to allow concurrent > disruptive GC (e.g. moving collectors like copying GC). > > If you enjoy learning about SableVM's stop-the-world protocol, go back > to reading the monitor enter/exit related code which is closely > related... > Too bad you didn't tape record your lecture at McGill. Maybe somebody took notes and could type them up (I didn't). Chris |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-03-31 16:35:05
|
Archie Cobbs wrote: > Presumably you could have simplified things by just waiting for all > threads to stop (instead of just waiting for non-JNI threads) before > GC'ing, but then you might have to wait an arbitrarily long time, > because a JNI thread could be doing something slow, sleeping, etc. 1) Non-JNI threads have at least one GC check point per loop iteration (this is a simplification of the reality which includes method entry, etc.) 2) Nothing prevents a JNI thread to go into a infinite loop, or not to call-back the VM, or to sleep indefinitely. So, it is reasonable to assume a non-JNI thread will soon reach a GC point, and it would be an error to wait for JNI threads to return or call back the VM before proceeding with GC. In fact, if you read the JNI spec carefully, you'll notice how direct access to a reference is never given to native code. You may rightfully deduce that this was made specifically to allow concurrent disruptive GC (e.g. moving collectors like copying GC). If you enjoy learning about SableVM's stop-the-world protocol, go back to reading the monitor enter/exit related code which is closely related... Etienne -- 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-03-31 16:15:55
|
Prof. Etienne M. Gagnon wrote: > As for JNI threads, as you correctly deduced, they cannot prevent GC, so > a count is not needed (the count is used to awaken the GC thread and > start GC). > > I know, this deserves *at least* a technical report. I'll evetually one > that describe the whole algorithm, when I get some time. Presumably you could have simplified things by just waiting for all threads to stop (instead of just waiting for non-JNI threads) before GC'ing, but then you might have to wait an arbitrarily long time, because a JNI thread could be doing something slow, sleeping, etc. In other words, this is the only reason I can think of for doing it the way you do (and indeed a good one)... but are there any others I'm missing? Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Precision I/O * http://www.precisionio.com |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-03-31 13:49:53
|
Paolino paperino wrote: > Hi, > now i can run SableVM with classpath correctly:-) but > i've another problem... > In my undergraduate thesis i need to modify the > sableVM interpreter, so could anyone send me the m4 > macros file that generate the *.c files based on > *.m4.c files? Or somebody knows where i could find > them.... Look at src/libsablevm/*.m4[.*], and in particular, read src/libsablevm/macros.m4. You should also read the following thread: http://sourceforge.net/mailarchive/forum.php?thread_id=1834524&forum_id=4154 Have fun! Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: David <db...@cs...> - 2003-03-31 13:48:33
|
On Mon, Mar 31, 2003 at 11:50:20AM +0200, Paolino paperino wrote: > Hi, > now i can run SableVM with classpath correctly:-) but > i've another problem... > In my undergraduate thesis i need to modify the > sableVM interpreter, so could anyone send me the m4 > macros file that generate the *.c files based on > *.m4.c files? Or somebody knows where i could find > them.... They should be distributed with the source. All macros are defined in *.m4.c and *.m4. Of course, you will need to have the m4 macro processor installed on your system, but it's probably already installed. The general macros are in macros.m4. David > Thanks a lot to anybody could give me some hints. > Andrea Selva >=20 > ______________________________________________________________________ > Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonin= o > http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.= html >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: ValueWeb:=20 > Dedicated Hosting for just $79/mo with 500 GB of bandwidth!=20 > No other company gives more support or power for your dedicated server > http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ > _______________________________________________ > 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: Prof. E. M. G. <eti...@uq...> - 2003-03-31 13:44:47
|
Hi Archie, You can view vm->pending_halt_thread_count as the count of Java threads (non-JNI) that have not yet reached a GC check point since GC was requested. So, when a Java thread reaches a GC point, it decreases this count and goes to sleep. When the count reaches 0, the GC thread is awaken and GC proceeds. As you probably know, a sleeping thread can be awaken for many reasons, yet it is important that any Java thread at GC point goes back to sleep if it is awaken before GC is done. As the thread is already at a GC point, the count is not modified. As for JNI threads, as you correctly deduced, they cannot prevent GC, so a count is not needed (the count is used to awaken the GC thread and start GC). I know, this deserves *at least* a technical report. I'll evetually one that describe the whole algorithm, when I get some time. Etienne Archie Cobbs wrote: > Archie Cobbs wrote: > >>Why in _svmf_stop_the_world() do you increase "vm->pending_halt_thread_count" >>for threads in state SVM_THREAD_STATUS_RUNNING_JAVA threads but not for >>threads in state SVM_THREAD_STATUS_NOT_RUNNING_JAVA_RESUMING_ALLOWED? > > > Ah.. now I think I see it.. > > It's because a thread's Java stack and its list of local native > references (in fact, it's total Java state) cannot change while > executing native code outside of libsablevm, because all JNI calls > that would permit such a thread to modify its Java state begin with > "_svmf_resuming_java()". So we can assume such threads are "halted" > even if they're still executing.. and if they attempt to cross back > into 'JAVA' mode they will see that resuming is disabled and then > they will halt. > > Does this sound correct? > > Thanks, > -Archie > > __________________________________________________________________________ > Archie Cobbs * Precision I/O * http://www.precisionio.com > > > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > 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: <von...@ya...> - 2003-03-31 09:50:26
|
Hi, now i can run SableVM with classpath correctly:-) but i've another problem... In my undergraduate thesis i need to modify the sableVM interpreter, so could anyone send me the m4 macros file that generate the *.c files based on *.m4.c files? Or somebody knows where i could find them.... Thanks a lot to anybody could give me some hints. Andrea Selva ______________________________________________________________________ Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html |
|
From: Archie C. <ar...@de...> - 2003-03-31 06:00:37
|
Archie Cobbs wrote: > Why in _svmf_stop_the_world() do you increase "vm->pending_halt_thread_count" > for threads in state SVM_THREAD_STATUS_RUNNING_JAVA threads but not for > threads in state SVM_THREAD_STATUS_NOT_RUNNING_JAVA_RESUMING_ALLOWED? Ah.. now I think I see it.. It's because a thread's Java stack and its list of local native references (in fact, it's total Java state) cannot change while executing native code outside of libsablevm, because all JNI calls that would permit such a thread to modify its Java state begin with "_svmf_resuming_java()". So we can assume such threads are "halted" even if they're still executing.. and if they attempt to cross back into 'JAVA' mode they will see that resuming is disabled and then they will halt. Does this sound correct? Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Precision I/O * http://www.precisionio.com |
|
From: Archie C. <ar...@de...> - 2003-03-31 05:45:05
|
Etienne- Why in _svmf_stop_the_world() do you increase "vm->pending_halt_thread_count" for threads in state SVM_THREAD_STATUS_RUNNING_JAVA threads but not for threads in state SVM_THREAD_STATUS_NOT_RUNNING_JAVA_RESUMING_ALLOWED? Either this is a bug or I'm missing something... Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Precision I/O * http://www.precisionio.com |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-03-30 23:21:29
|
Hi All. I have started the process of updating sablepath-classes & sablepath-libs to the latest GNU Classpath CVS image. This will most probably BREAK sablevm. I will need help to test SableVM and fix any bugs this update has introduced. To help working on this, it would be best if people made suggestions on the CVS repository organization. One important question I have already raised, and that we should address quickly [a manager would say: yesterdday! ;-)] is: > To be decided: Where do we put the experimental class/native > libraries? I was thinking of putting them in subdirectories of > sablevm-experimental. What do you think? The objective is to get rid of sablepath-libs & sablepath-classes as soon as possible, making sure SableVM users can directly use GNU Classpath, instead. But, this will require merging our local changes into Classpath CVS. Before we can do that, we have to make sure that "current Classpath CVS + local SableVM-specific changes = working SableVM". Please let me know your opinion about the sablepath-* vs sablevm-experimental question. Also, If you are willing to help with the sablepath update, just say so. :-) Thanks a lot in advance! Etienne -- 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-03-29 19:41:35
|
Hi there. Has anybody started working on an implementation of Thread.interrupt() and thread.interrupted() yet? If yes, could you send your preliminary code to this list (as unified diffs against current CVS, ideally [e.g. cvs diff -u])? Thanks, Etienne Mark Howard wrote: > Sorry. I've tried it again and noticed that I probably gave you > completely the wrong information. Here is the full output: > > > *** Couldn't bind native method Java_java_lang_Thread_interrupted *** > *** or Java_java_lang_Thread_interrupted__ *** > java.lang.UnsatisfiedLinkError > at java.lang.Thread.interrupted(Thread.java) > at com.tildemh.debbug.CacheWriter.run(CacheWriter.java:44) > at java.lang.Thread.callRun(Thread.java:372) > at java.lang.VirtualMachine.runThread(VirtualMachine.java:117) |
|
From: Prof. E. M. G. <eti...@uq...> - 2003-03-27 18:46:55
|
Hi Christian,
I am CC'ing the sablevm-developer ML, as my answer might also help others.
Christian ROY wrote:
> I'm curious about something. I'm currently using marking to determine
> what elements of the stack are reference types. I've come accross a
> behavior I'd like to have clarified. Before a method is invoked the object
> refrerence is pushed onto the stack and so are the arguments. When the new
> method begins it creates it own stack frame and sets its local from
> the previous values of the old stack frame. So the object reference is
> placed in local[0] and the arguments in local[1] ... to local[n]. How do
> you distinguish which of these arguments are references and which are not?
There is a bitmap used to indicate which of the "parameter" locals are references.
Look at src/libsablevm/types.h:
...
struct _svmt_method_info_struct
{
...
jint java_args_count; /* int,ref,boolean,... = 1; double, long = 2 */
_svmt_gc_map_node *parameters_gc_map;
...
This is not sufficient for tracing all locals, as you also have to consider
locals which are not parameters. The reference-yet-not-parameter locals are all
grouped together, just after the parameter locals. See:
...
struct _svmt_method_frame_info_struct
{
...
/* number of non-parameter reference local variables */
jint non_parameter_ref_locals_count;
...
Please look at src/libsablevm/gc_copying.c for an example of how to use them, e.g.
/* method formal parameters */
{
jint i;
jint count = parameters_gc_map->size;
for (i = 0; i < count; i++)
{
if (_svmf_get_bit (parameters_gc_map->bits, i))
{
locals[i].reference =
_svmf_copy_object (env, locals[i].reference,
pto_space_tail);
}
}
}
/* other ref locals */
{
jint i;
jint start = method->java_args_count;
jint end = start + non_parameter_ref_locals_count;
for (i = start; i < end; i++)
{
locals[i].reference =
_svmf_copy_object (env, locals[i].reference,
pto_space_tail);
}
}
I hope this helps.
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
|
|
From: David <db...@cs...> - 2003-03-26 15:45:21
|
On Wed, Mar 26, 2003 at 11:34:39AM +0100, Paolino paperino wrote: > Hi=20 > Thanks a lot for the hints of the last time! But now > i've the some questions about the same argument. > When i compile SableVM, the "make install" puts an > executable named sablevm in /usr/local/bin, well is > this the INSTALLDIR you referenced last time? So i > might put the classes subtree (that i found in > sable-class-library package) in the /usr/local/bin/lib > (with a symbolic link i thought)? Did you successfully install the native library? There is some info in INSTALL. To summarize there are 3 things to compile and install. - sablevm - native lib - class lib You need to run the build script to build it. Make sure all component are built properly. Note that the build script is more an example and you may need to specify other info such as include path etc. Note that the build script continue to the next component on error. You should get the dir structure: DIR/bin/sablevm DIR/lib/libsablevm.so.VER and several sym link DIR/lib/sablevm/classes-VER/* (several directories with *.class files) DIR/lib/sablevm/ libclasspath-VER , libjavaio-VER etc (native libs) A few installation scripts have been posted on this mailing list, they may be easier to use. > Now i tried this solution but it don't work, i always > get :"sablevm: cannot create a vm". >=20 This is a very general error message and doesn't tell much about the spec= ific problem. try: sablevm -v -p sablevm.verbose.methods=3Don -p sablevm.verbose.instructions=3Don yourclass to see how far it gets. > Could yoo create a file with the complete installation > instructions (please :-)). I this file could help > other SableVM newbye users! There is one call INSTALL. However, I do agree that SableVM is somewhat difficult to compile and install. There is a Debian package and hopefully other Unix system will package it to make installation easier. David > Thanks a lot for the time spent > Andrea Selva >=20 > ______________________________________________________________________ > Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonin= o > http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.= html >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > 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: <von...@ya...> - 2003-03-26 10:34:47
|
Hi Thanks a lot for the hints of the last time! But now i've the some questions about the same argument. When i compile SableVM, the "make install" puts an executable named sablevm in /usr/local/bin, well is this the INSTALLDIR you referenced last time? So i might put the classes subtree (that i found in sable-class-library package) in the /usr/local/bin/lib (with a symbolic link i thought)? Now i tried this solution but it don't work, i always get :"sablevm: cannot create a vm". Could yoo create a file with the complete installation instructions (please :-)). I this file could help other SableVM newbye users! Thanks a lot for the time spent Andrea Selva ______________________________________________________________________ Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html |
|
From: Grzegorz B. P. <ga...@de...> - 2003-03-25 09:08:20
|
Hi! SableVM hasn't been built on m68k yet and it seems it won't be in next hours and maybe days (see attachemment). I was also denied installation of build-deps of sablevm on crest - the m68k machine available for DDs which is also serving as an autobuilder (attachement again). I am afraid there's not much I can do about it because a) I don't have access to any m68k machine but crest b) at the moment I don't have time to hunt m68k owners on #debian-devel c) tomorrow I am leaving for "penguinaries" - an unofficial, underground ;-) polish Linux conference (where I will have lectures about the SELinux and the Hurd) and I'll be back on sunday evening. So all I can do currently is to post my patch untested on m68k. I am quite sure that it will work on m68k, just like all other ports worked. I'd prefer to submit full patch, including untested parts for mips and mipsel which I hope will be useful at some time point. I'll do that in the evening. Grzegorz B. Prokopski -- Grzegorz B. Prokopski <ga...@de...> Debian http://www.debian.org/ |
|
From: David <db...@cs...> - 2003-03-24 22:40:27
|
Hello, When testing my JIT with athrow I noticed this and I thought it would be good to report it. The PREPARE_INVOKE* special instruction both prepare the method and invok= e it. The REPLACE instruction is after the PREPARE_INVOKE*. This means that if the methods terminates abruptly due to an exception the REPLACE will not get executed. This will not lead to incorrect behaviour but if the method is always throwing exception at a call site, the REPLACEment will never occur for that call site. If it is always throwing exception, the previous statement applies to all call sites. Since this is a rare case and exceptions are already inefficient it may not be worth the effort to change. (My JIT compiler was never compiling my test method for this reason since= I didn't have a JIT entry point in that code.) David --- 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: Prof. E. M. G. <eti...@uq...> - 2003-03-24 05:30:15
|
Hi All,
Today, I have added a sablevm-experimental module on CVS and activated
commit controls in CVS as follows:
- All registered developers have write access to
- sablevm-experimental (trunk only)
- sablevm/doc (trunk only)
sablevm-experimental has a vendor branch containing an image of the
latest sablevm module trunk, that I will regularly update.
I have set up the repository this way in prevision of the following
development model:
1- The sablevm module should always be in a "releasable" state. Write
access to it is highly restricted (temporary or permanent write access
negotiable on a developer basis).
2- The sablevm-experimental module should be kept, as much as
possible, in a relatively stable state. When you checkin your
"special enhancements" (e.g. JIT, speculative code, whatever), you
should hide them within C #ifdef conditionals (with an appropriate
entry in configure.ac). You can also put some personal
code/documentation in sablevm-experimental/developer/your-username **
if and only if ** it is licensed under SableVM's license, as usual.
3- 2 ways for testing your stuff:
a) checkout sablevm, apply you changes, test them, use
"cvs diff -u -N" to get unified diffs to submit in the tracker.
b) checkout sablevm-experimental, apply your changes, checkin your
changes, ask other developers to test. Go back to a) for
preparing a patch.
To be decided: Where do we put the experimental class/native
libraries? I was thinking of putting them in subdirectories of
sablevm-experimental. What do you think?
Any comment on this development model?
Etienne
--
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-03-24 05:07:23
|
On Sun, Mar 23, 2003 at 10:32:28PM +0100, Grzegorz B. Prokopski wrote: > I won't be posting my patches yet, but I'd just like to say that > I already have SableVM working on s390 architecture (build by > an autobuilders a few days ago) and arm (build today by me). Great! When you are ready, you can submit your patches using the newly activated Patch Tracking System: http://sourceforge.net/tracker/?atid=3D305523&group_id=3D5523&func=3Dbrowse > Unfortunatelly it seems that for now we'll be stuck with 8 debian arches > for some time because libffi is not available on the remaining 2 > (or some say 3) arches: hppa, mips and mipsel. The arch-specific parts > of SableVM for mips and mipsel are ready [1]. > Hppa will require some more investigation to find out the needed > assembler parts but it doesn't make much sense to start the effort > before we have libffi for hppa. We will eventually have to port libffi to these platforms. If anybody on this list already knows about calling conventions on these systems, he/she is welcome to help! > I think that the next step will be testing inlined-threading on > non-x86 which, as Etienne experienced, won't be *that* plain easy > as it seemed in the beginning. One of the most important parts, for porting the inline-threaded engine, is to test the inlinability of each bytecode. To this end, I need a class written in bytecode assembly (e.g. Jasmin) that does test every single Java bytecode. It ould look something like: [I'm using Java-like pseudo-code] class TestBytecodes { void test_NOP() { NOP RETURN } ... void test_IADD() { ICONST 500 ICONST 18273 IADD RETURN } ... } Ideally, the source file size would be kept to a minimum using existing m4 macros (see src/libsablevm/macros.m4) or new ones (derived =66rom macros.m4, if required for jasmin code). Any volunteer to help? 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: Grzegorz B. P. <ga...@de...> - 2003-03-23 21:33:34
|
Hi! I won't be posting my patches yet, but I'd just like to say that I already have SableVM working on s390 architecture (build by an autobuilders a few days ago) and arm (build today by me). The m68k version should be build by tomorrow - it has been just moved to the next-to-be-built position in the queue of the fastest available m68k autobuilder [0]. I expect success here also. The test ran is simple "HelloWorld" for now which is being run as a part of package build process (and if running it fails - whole build fails and package is not created nor uploaded). I have accumulated quite a lot of arch-specific changes in my tree so I'd really like to have them all in 1.0.9 as soon as they're proved to be working. There are also some cosmetic changes, like sorting the arch-specific stuff alphabetically by arch symbol. Unfortunatelly it seems that for now we'll be stuck with 8 debian arches for some time because libffi is not available on the remaining 2 (or some say 3) arches: hppa, mips and mipsel. The arch-specific parts of SableVM for mips and mipsel are ready [1]. Hppa will require some more investigation to find out the needed assembler parts but it doesn't make much sense to start the effort before we have libffi for hppa. I think that the next step will be testing inlined-threading on non-x86 which, as Etienne experienced, won't be *that* plain easy as it seemed in the beginning. Gotta hand-upload the arm version. Will keep you informed. Cheers, Grzegorz B. Prokopski PS: It seems that GNU Classlib has never been used on s390 yet. I had to patch endiannes information to include s390 (I hope I won't forget to send that 4 lines long patch also). [0] which is currently busy with koffice so it'll take a while :-/ [1] the assembler parts (atomic c&s) for mips and mipsel are untested --=20 Grzegorz B. Prokopski <ga...@de...> Debian http://www.debian.org/ |
|
From: Archie C. <ar...@de...> - 2003-03-21 18:30:07
|
Prof. Etienne M. Gagnon wrote: > > Along these lines, below are some patches I submitted to Classpath > > (against their version 0.05) for implementing several reflection > > methods non-natively instead of natively and relying on fewer native > > methods. > > Would you be interested in getting CVS write access? I assume you have > clean-room status, own your code, and agree to license it appropriately? Sure, that'd be great.. I'm even still unpolluted by Sun :-) > [For SableVM-specific code, I ask that you license it under SableVM's license > (LGPL), and that you keep ownership of the Copyright on your contributions. I > additionally ask you to to grant me permission to make minor modifications to > the license terms (add an exception, for example), in case a problem is found > later that would prevent SableVM achieve its objectives, including: > 1- Remaining Free, yet also > 2- Be usable to run non-Free programs. > > I don't think using such an exception will be necessary, as the GNU LGPL already > seems to achieve this goal, but some people think that using SableVM in the > embedded world could require some special exception]. > > Also, as this is part of the class library, I ask of SableVM developers making > significant changes in that part to fill out the FSF papers to assign their > modifications to Classpath back to the FSF (as I will merge all these changes > into Classpath CVS at an appropriate time). > > It also simplifies the maintenance of file headers: no need to add the names of > additional copyright holders (other than the FSF) in class-library files. > > Maybe you already have signed the FSF papers? [If not, I am sure Classpath > people will ask you for it before committing any substantial patch of yours; FSF > policy]. That all sounds fine. I'm already in the process of doing the Classpath assignment as well. Thanks, -Archie __________________________________________________________________________ Archie Cobbs * Precision I/O * http://www.precisionio.com |
6 messages has been excluded from this view by a project administrator.
