sablevm-developer — SableVM developer mailing list

Re: [Sablevm-developer] while building ant... and some other stuff

[Grzegorz P. <ga...@de...>]

W li=B6cie z nie, 11-08-2002, godz. 14:17, Grzegorz Prokopski pisze:=20
> Hello!
>=20
> My first mail, sent to sablevm-developer list (after I subscribed)
> still hasn't reached my mailbox. So I am Cc:ing Etienne.
I seem to be getting the mail from ml but it takes hours... we'll see...

> So as I said before - I tried to compile ant. the critical part, that
> gives me problems is this:
The new version of jikes I belive - really was causing trobules.
I reverted to older version, recompiled all sablevm-classpath stuff
(and cleaned/polished the packages - they're almost ready)
and I am getting this now:

greg@greg:/opt/media/build/ant-1.5$ /usr/bin/java -classpath
build/classes:src/main::/usr/share/java/antlr.jar:/usr/share/java/bsf.jar:
/usr/share/java/junit.jar:/usr/share/java/log4j.jar:/usr/share/java/oro.jar=
:
/usr/share/java/regexp.jar:/usr/share/java/xalan2.jar:
/usr/share/java/xercesImpl.jar:/usr/share/java/xml-apis.jar:
/usr/lib/sablevm/classes:/usr/lib/tools.jar -Dant.home=3D.
org.apache.tools.ant.Main -emacs jars javadocs

java.lang.ClassNotFoundException: build/classes:src/main::
 /usr/share/java/antlr.jar:/usr/share/java/bsf.jar:/usr/share/java/junit.ja=
r:
 /usr/share/java/log4j.jar:/usr/share/java/oro.jar:/usr/share/java/regexp.j=
ar:
/usr/share/java/xalan2.jar:/usr/share/java/xercesImpl.jar:
/usr/share/java/xml-apis.jar:/usr/lib/sablevm/classes:/usr/lib/tools.jar
	at gnu.java.lang.SystemClassLoader.findClass(SystemClassLoader.java:73)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:308)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:259)
	at java.lang.VirtualMachine.main(VirtualMachine.java:79)

[I removed self-advertising stuff]

Which class is missing? java.lang.VirtualMachine ?

I am doing sth wrong - am I?

					Grzegorz B. Prokopski

PS: I will not continue sending such requests for help while compiling
programs with sablevm once I am sure that I have it up and working.
Now I am not, so I am plying this "FYI: error and HINTs please" game.

[Sablevm-developer] while building ant... and some other stuff

[Grzegorz P. <ga...@de...>]

Hello!

My first mail, sent to sablevm-developer list (after I subscribed)
still hasn't reached my mailbox. So I am Cc:ing Etienne.

So I have got early packages, they're:
sablevm
sablevm-nativelib
sablevm-classlib

It is very nice that /usr/bin/sablevm is designed to be replacement
of /usr/bin/java.
It is also very nice that it doesn't need to be given classpath path
on the commandline, however I'd like it to search not only for
/usr/lib/sablevm/classes-$VERSION, but at least for
/usr/lib/sablevm/classes if the above is not found.
(it will be a symlink to /usr/share/sablevm/classes anyway, but that's
another story)

So as I said before - I tried to compile ant. the critical part, that
gives me problems is this:

/bin/sh bootstrap.sh
... Bootstrapping Ant Distribution
... Compiling Ant Classes
... Copying Required Files
... Building Ant Distribution
/usr/bin/java -classpath
build/classes:src/main::/usr/share/java/antlr.jar:/usr/share/java/bsf.jar:
/usr/share/java/junit.jar:/usr/share/java/log4j.jar:/usr/share/java/oro.jar=
:
/usr/share/java/regexp.jar:/usr/share/java/xalan2.jar:
/usr/share/java/xercesImpl.jar:/usr/share/java/xml-apis.jar:
/usr/lib/sablevm/classes:/usr/lib/tools.jar -Dant.home=3D.
org.apache.tools.ant.Main -emacs jars javadocs

SableVM version 1.0.1
Copyright (C) 2000-2002 Etienne M. Gagnon <eti...@uq...> and
others.  All rights reserved.

This software comes with ABSOLUTELY NO WARRANTY.  This is free
software, and you are welcome to redistribute it under certain
conditions.

To get the name of all copyright holders and detailed license
information, type "sablevm --license" or look in the directory
"/usr/share/sablevm".

The SableVM web site is located at http://www.sablevm.org/ .

java/lang/UnsatisfiedLinkError
... Failed Building Ant Distribution !


It works with kaffe and blackdown 1.3 java.
Any hints are welcome. On my side - I was told that the latest jikes,
which is currently in unstable (I use unstable, so I used this version
of compiler too) - has some serious problems. I'll try to recompile
sablevm-classpath with previous version and if that changes anything
- I'll tell you.

Regards

				Grzegorz B. Prokopski

PS: As I am not sure if my subscription works (I have received message
that claims I _am_ subscribed) - please Cc: me.
I don't understand why in sablevm-developer archive at
http://sourceforge.net/mailarchive/forum.php?forum_id=3D4154
newest message is dated 2001-09-24 ?

PSS: Is this really needed to show all that long information about
SableVM and all stuff about it when the only important part is
one-liner message about error?
IMVHO a kind of 2-4 liner information would be more in place here.

PST: It would be nice to have a kind of JAVA_HOME environment.
Is there some documentation about what should be there?
(I can _look_ at what kaffe/blackdown put there of course) -
what do you think of JAVA_HOME? How should it be set for SableVM?

Re: [Sablevm-developer] trying SableVM in Debian

[Grzegorz P. <ga...@de...>]

W li=B6cie z nie, 11-08-2002, godz. 02:43, Etienne M. Gagnon pisze:=20
> Etienne M. Gagnon wrote:
> > On the benchmark side, I have yet to see Kaffe run all of the SPECjvm98=
=20
> > benchmarks, SableCC and Soot.
>=20
> To be honest, my current experiments show that the latest verions of Kaff=
e has=20
> been fixed to run all of SPECjvm98.  I'm still trying to get SableCC and =
Soot to=20
> run on it, though.
Yes, kaffe 1.0.7 is MAJOR step forward.
The number change 1.0.6->1.0.7 doesn't show how much effort was put
into it since previous release.

Oh - and it is being ported to all Debian architectures (just released
Woody has 11 of them).

While we're at it - what's the status of ports of SableVM?
From what I could read using that ugly SF archive - it works on i386
and Alpha. Any others? Are there plans/people working on new ones?

Regards

					Grzegorz B. Prokopski

PS: I _am_ subscribed to -dev list now - you don't _need_ to Cc: me (but
you may as it makes no difference at all for me)

Re: [Sablevm-developer] trying SableVM in Debian

[Etienne M. G. <eti...@uq...>]

Etienne M. Gagnon wrote:
> On the benchmark side, I have yet to see Kaffe run all of the SPECjvm98 
> benchmarks, SableCC and Soot.

To be honest, my current experiments show that the latest verions of Kaffe has 
been fixed to run all of SPECjvm98.  I'm still trying to get SableCC and Soot to 
run on it, though.

Etienne
-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] trying SableVM in Debian

[Etienne M. G. <eti...@uq...>]

Etienne M. Gagnon wrote:
> =B7=B7=B7   For example, it cannot run the stable version
> of SableVM (2.16.2),=20

I meant SableCC, of course.

Have fun!

Etienne
--=20
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] trying SableVM in Debian

[Etienne M. G. <eti...@uq...>]

Hi Grzegorz,

Grzegorz Prokopski wrote:
> 1. I fetched all three source tarballs.
> sablevm and sablevm-native-library compiled w/o problems but
> how am I supposed to compile sablevm-class-library when there's
> no autogen/configure/Makefile in it?
> I think I _could_ copy them from original classlib sources, but
> it ain't right soulution. Is this an oversight or are there reasons
> for not including any build machinery into this source tarball?


There is a README file in the sablevm-1.0.1.tar.gz files as well as a convenient 
"build" script which you could inspect, if you want to cutomize destination 
directories (which is probably the case).

Mainly, you compile the classes using a bash script which looks like:

tar -xzf sablevm-class-library-$VERSION.tar.gz
cd sablevm-class-library-$VERSION
mkdir classes
find | grep \\.java$ | xargs jikes -g -d classes \
  -bootclasspath src:classes -classpath src:classes -sourcepath src
find resource -type f | cut -d\/ -f2- | \
  awk '{print "cp resource/" $0 " classes/" $0 }' | sh
chmod -R a+rX classes
rm -rf $LOCATION/lib/sablevm/classes-$VERSION
mv classes $LOCATION/lib/sablevm/classes-$VERSION
cd ..

> 2. More general. I looked at changelog and TODO list to get some
> impression in what state SableVM is ATM. However I'd like to ask
> you few simple question.

The TODO is GNU Classpath's todo.  Do not confuse Classpath and SableVM. No, I 
have NOT included a TODO file with SableVM.

I have been able to run all the SPECjvm98 benchmarks, including the 
multi-threaded ones, very reliably.  I have also been able to run things like 
"SableCC 2.17.3" to generate a parser for the (huge) java grammar (this is 
something I have yet to see Orp, Kaffe, Kissme, Japhar or any other do).  Even 
better, I have been able to run Soot 1.2.3, which even breaks some of IBM's 
flagship JITs.

Of course, I have not tested SableVM with all possible applications, and it has 
its shortcomings.  For example, it cannot run the stable version of SableVM 
(2.16.2), because of incomplete implementation or Serialization in Classpath (or 
bugs in Classpath?).  And even if Classpath was fixed, there might yet be some 
missing support in SableVM.  I think it would need to implement things like 
Field.getModifiers() [which is fairly simple to implement, maybe 5 lines of code?].

SableVM supports class loaders; in fact all "application" classes are loaded 
through a Java written Class loader.  So, you can type things like (assuming 
sablecc-2.17.3):

sablevm --classpath sablevm.jar:java-getopt.jar org.sablecc.sablecc.SableCC

> - can I use jar files w/o problems (it was mentioned in changelog
> as done, but in TODO list there was sth. about zip files not being
> supported and jars treated as zips - so finally not sure here)

See example above.  Now, SableVM does not yet support writing:

sablevm -jar executable.jar

But, this should be fairly simple to implement.  I won't personally do it now, 
as I am writing my Thesis. But, if no contributor does it within the next month, 
I'll probably do it then.

> - what classpath integration pieces are missing? 
> Can I use their gtk-peers? What will those missing pieces impact?

There's so much a single person can do... Why don't you try it by yourself and 
tell me what's missing, so that I (or others) fix it?

> - do you see yourself as research mainly project? I mean - do you
> want your JVM to be developed and used seriously or...

I want the JVM to be developed and used seriously.  Now, it is an INTERPRETER, 
not a JIT (but there are already projects to eventually add a JIT).  The idea is 
that it is an efficient and portable interpreter.  Depending on the application, 
it can compare sometimes favorably to Sun's "Java -Xint".  This is an order of 
magnitude faster than Kaffe's interpreter (and most other interpreters).  With 
the big difference that SableVM is written in portable ISO C (with optional GNU 
extentions for direct/inlined threading), and only assumes a POSIX system library.

The implementation of JNI and the Invoke interface, does the right things around 
native calls.  The "precise" garbage collector doesn't fail in presence of 
complex jsr/exception mixes. etc.

This was the whole point behind writing an interpreter: to have time to make it 
robust, and as complete as possible.

Now, of course, it is ALSO meant as a research vehicle.  But the idea is to 
allow doing research with a VM that is able to run real-world applications, not 
only bechmarks.

The SableVM will remain entirely dependent on the GNU Classpath project, for its 
class libraries.  Implementing a robust VM is already enough work for an 
academic research team!  So, as long as Classpath won't have solid AWT support, 
SableVM will lack in that department, etc.

> - Currently we seem to have a lot free JVMs available. Why is your
> so different? better than the others? - so you decided to hack on
> that one not on them?

Robustness.  Off the top of my head... I wanted a VM that would have:
1- A clean implementation of JNI and the Invoke interface. Did you know that 
SableVM allows for more than one VM in a single process, living or distinct 
threads, of course?
2- Innovative memory management.
3- Low learning curve for new developers.
4- Allows for easily adding new kinds of bytecode instructions (for reasearching 
things like VM support for parametric types).
5- Was built with both portability AND efficiency in mind.  JITs are efficient, 
but not portable. Most interpreters are (sometime) portable and (most of the 
time) very, very slow, unless parts are coded in assembly.  (Even if the 
JikesRVM is written in Java, it is not easily portable; targetting a new 
platforms involves modifying 3 optimizing compilers!)
6- More...  Read the paper referenced on the SableVM web page.  It has a fairly 
good motivation section which should be simple to read.

> - how would you compare your JVM with classpath duo to what kaffe
> is (technically)? Do you have any (more-less accurate) benchmarks?

Kaffe is GPL'ed without exception.  So you might be introuble for running 
proprietary applications, if you strictly follow the license.

On the benchmark side, I have yet to see Kaffe run all of the SPECjvm98 
benchmarks, SableCC and Soot.

> Can you run all the apps that kaffe can run? more? less?
> Where are the problems? When will they probably be solved?

You tell me.

> I'd like to know what you can say about the above. If I decide to
> carry on maintaining SableVM - I'd like to know what I am putting
> myself into.

You might also want to discuss with Brent Fulgham (another Debian developer). I 
think he was also interested in packaging SableVM.  But, sometimes he takes a 
while to read his mail...

>>From practical POV - we (in Debian) don't really need tenth JVM that
> works just like all the other. So far it seems that you're better
> because of:
> 1. no licensing problems (kaffe and it's libs are GPL)
> 2. support for jars (strange, but some other free JVMs need to have
> classes unpacked first - which is hardly acceptable)

Most other free VM's have big shortcomings in the areas of ClassLoaders and 
applying the correct Class Initialization procedures.  It's far from easy to get 
right.  Also, getting precise garbage collection (instead of plugging a 
conservative collector) in absence of verifier is quite tricky (as I explain in 
my thesis).  At first sight, Orp seems to have got this one wrong.

I repeat: SableVM was built with robustness in mind.

> 3. integration with classpath (java 1.2, a bit more than kaffe has)
> 
> Thank you for all your answers and thoughts. Please Cc: me.
> 

I won't have much time to debate this further.  I have, unfortunately, a thesis 
to finish writing.  Experiment with SableVM, look at its source code, if you are 
litterate in C, and I'm pretty sure you'll like it.  I encourage you to also 
look at the source code of other free VM's and notice the differences in the 
approach.

Etienne
-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

[Sablevm-developer] trying SableVM in Debian

[Grzegorz P. <ga...@de...>]

Hi!

There has been RFP (Request for packaging) filled on SableVM.
I have not yet decided to get on it, to create and maintain SableVM
in Debian - I'd like to try it first. And I have a couple of questions.
Please Cc: me as I am not subscribed to the list.

1. I fetched all three source tarballs.
sablevm and sablevm-native-library compiled w/o problems but
how am I supposed to compile sablevm-class-library when there's
no autogen/configure/Makefile in it?
I think I _could_ copy them from original classlib sources, but
it ain't right soulution. Is this an oversight or are there reasons
for not including any build machinery into this source tarball?

2. More general. I looked at changelog and TODO list to get some
impression in what state SableVM is ATM. However I'd like to ask
you few simple question.
- can I use jar files w/o problems (it was mentioned in changelog
as done, but in TODO list there was sth. about zip files not being
supported and jars treated as zips - so finally not sure here)
- what classpath integration pieces are missing?=20
Can I use their gtk-peers? What will those missing pieces impact?
- do you see yourself as research mainly project? I mean - do you
want your JVM to be developed and used seriously or...
- Currently we seem to have a lot free JVMs available. Why is your
so different? better than the others? - so you decided to hack on
that one not on them?
- how would you compare your JVM with classpath duo to what kaffe
is (technically)? Do you have any (more-less accurate) benchmarks?
Can you run all the apps that kaffe can run? more? less?
Where are the problems? When will they probably be solved?

I'd like to know what you can say about the above. If I decide to
carry on maintaining SableVM - I'd like to know what I am putting
myself into.

From practical POV - we (in Debian) don't really need tenth JVM that
works just like all the other. So far it seems that you're better
because of:
1. no licensing problems (kaffe and it's libs are GPL)
2. support for jars (strange, but some other free JVMs need to have
classes unpacked first - which is hardly acceptable)
3. integration with classpath (java 1.2, a bit more than kaffe has)

Thank you for all your answers and thoughts. Please Cc: me.

Best regards

					Grzegorz B. Prokopski

[Sablevm-developer] SableVM 1.0.1

[Etienne M. G. <eti...@uq...>]

Changes:
========

- SableVM now waits until all non-daemon threads are died before
quitting.

- SableVM is now known to run all SPECjvm98 benchmarks, SableCC
2.17.3, and Soot 1.2.3.

- Convenient build scripts have been added.

Notes:
======

To install SableVM, you must download the three files:
- sablevm-x.y.z.tar.gz
- sablevm-class-library-x.y.z.tar.gz
- sablevm-native-library-x.y.z.tar.gz

Then, uncompress the sablevm-x.y.z.tar.gz file (tar -xzf) and follow
the instructions in the README file.

You can change many options in SableVM throught the configure script.
For example, you can type "./configure -with-object-layout=traditional".
Try "./configure --help" and read the generic INSTALL file for more
information.


Etienne
-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

[Sablevm-developer] SableVM 1.0.0

[Etienne M. G. <eti...@uq...>]

I am pleased to announce the official release of SableVM version 1.0.0.
This version includes all of the promised features: 3 flavors of
threading, bidirectional/traditional object layout, sparse interface
vtables, spinlock-free thinlocks, low cost maps for precise GC, grow
as needed Java stack, signal (or not) based null checks, and much
more.

As usual, you can download the sources from http://www.sablevm.org/ .

To the pleasure of hearing from you on the sablevm-user list!

Etienne
-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] Properties

[Ian R. <ir...@cs...>]

Hi,

> > The last property stops the JVM trying to load
> > gnu/java/io/decode/DecoderISO-8859-1 and switches it to loading
> > gnu/java/io/decode/Decoder8859_1 . If the default action is to load
> > DecoderISO-8859-1 then shouldn't the java file be called
> > DecoderISO-8859-1 rather than Decoder8859_1 ?
> 
> My JVM worked fine until an application specifically requested an encoding type.

My code failed when java/util/Properties was used. This requested the
ISO-8859-1 encoding type to load properties from a file on disk. It's a
shame properties need to be set in order to load properties. If this
weren't the case then JVMs using classpath could load all their specific
properties in from disk.

Ian

Re: [Sablevm-developer] Properties

[John L. <je...@pi...>]

> Well I'm back to the stage I was at before I moved over to sablepath
> from a classpath 0.02. I found that I had to set a rather obscure
> property. Surely the VM integrators guide should mention these things.
> The property needed to be set so that EncodingManager could be used to
> load some other properties. Anyhow, the list of properties I set in
> VMSystem.insertSystemProperties is:
> line.separator - \n
> file.separator - /
> path.separator - :
> gnu.java.io.encoding_scheme_alias.ISO-8859-1 - 8859_1

See my recent post to the Classpath list.
 
> The last property stops the JVM trying to load
> gnu/java/io/decode/DecoderISO-8859-1 and switches it to loading
> gnu/java/io/decode/Decoder8859_1 . If the default action is to load
> DecoderISO-8859-1 then shouldn't the java file be called
> DecoderISO-8859-1 rather than Decoder8859_1 ?

My JVM worked fine until an application specifically requested an encoding type.

John

Re: [Sablevm-developer] More on bootstrapping

[John L. <je...@pi...>]

> > If I understand it correctly, you're now hardcoding the separator in your Runtime file?
> 
> The original Runtime file had a mix of hardcoded ':'s and
> File.pathSeparatorChar. The use of File led to Runtime being re-entered
> when it hadn't been statically initialised. To stop this I hardcoded the
> pathSeparatorChar in Runtime.Runtime to ':'. I would like to use a
> property to read the path seperator character but it's not obvious how
> to without bootstrapping problems. One ugly solution would be to have a
> native getPathSeperatorChar method. Anyhow, thoughts and comments
> appreciated.

Just checking.

A native method might be a solution, it's not hard at all.

You might find (later on), that reducing the depth of the call stack during initialization of the class libraries can ease debugging.

(Which is why removing circular dependencies is a good thing).

John Leuner

[Sablevm-developer] Properties

[Ian R. <ir...@cs...>]

Hi,

Well I'm back to the stage I was at before I moved over to sablepath
from a classpath 0.02. I found that I had to set a rather obscure
property. Surely the VM integrators guide should mention these things.
The property needed to be set so that EncodingManager could be used to
load some other properties. Anyhow, the list of properties I set in
VMSystem.insertSystemProperties is:
line.separator - \n
file.separator - /
path.separator - :
gnu.java.io.encoding_scheme_alias.ISO-8859-1 - 8859_1

The last property stops the JVM trying to load
gnu/java/io/decode/DecoderISO-8859-1 and switches it to loading
gnu/java/io/decode/Decoder8859_1 . If the default action is to load
DecoderISO-8859-1 then shouldn't the java file be called
DecoderISO-8859-1 rather than Decoder8859_1 ?

Anyhow, I'd love to know if I'm missing any obvious properties I'm
forgetting to set. Are the .properties files being pulled across from
classpath to sablepath? Should we alter the decoder naming scheme?

All the best,

Ian Rogers
-The University of Manchester
-http://www.cs.man.ac.uk/~rogersi5/

Re: [Sablevm-developer] More on bootstrapping

[Ian R. <ir...@cs...>]

Hi John,

> If I understand it correctly, you're now hardcoding the separator in your Runtime file?

The original Runtime file had a mix of hardcoded ':'s and
File.pathSeparatorChar. The use of File led to Runtime being re-entered
when it hadn't been statically initialised. To stop this I hardcoded the
pathSeparatorChar in Runtime.Runtime to ':'. I would like to use a
property to read the path seperator character but it's not obvious how
to without bootstrapping problems. One ugly solution would be to have a
native getPathSeperatorChar method. Anyhow, thoughts and comments
appreciated.

Ian

Re: [Sablevm-developer] More on bootstrapping

[John L. <je...@pi...>]

> I'm free to modify java/lang/Runtime all I want as it is a VM specific
> file :-) It seems badly written too as it half uses ':' as a path
> seperator and half uses File.pathSeperatorChar. The System.setProperty
> -> Hashtable.hash -> Math.<clinit> -> System.loadLibrary ->
> Runtime.loadLibrary -> ... bootstrapping problem seems to be resolved by
> modifying Runtime.Runtime too :-) Anyway my modifications are attached
> as a patch. I'll commit them if anyone wants.
> 
> Ta,
> 
> Ian
> Index: sablepath-classes/src/java/lang/Runtime.java
> ===================================================================
> RCS file: /cvsroot/sablevm/sablepath-classes/src/java/lang/Runtime.java,v
> retrieving revision 1.1.1.2
> diff -r1.1.1.2 Runtime.java
> 45a46,47
> > 		char pathSeparatorChar = ':';
> > 
> 55c57
> < 			if(path.charAt(i) == ':')
> ---
> > 			if(path.charAt(i) == pathSeparatorChar)
> 63c65
> < 			int next = path.indexOf(File.pathSeparatorChar,current);
> ---
> > 			int next = path.indexOf(pathSeparatorChar,current);
> 164a167

If I understand it correctly, you're now hardcoding the separator in your Runtime file?

John Leuner

Re: [Sablevm-developer] Off topic (probably)

[Etienne M. G. <eti...@uq...>]

Ian Rogers wrote:

>>>My new problems are caused by the way my JVM works. I run class
>>>initialisers as soon as a bytecode is executed that references the
>>>uninitialised class.
>>>
>>Mine is even more eager than that; it initializes a class when it
>>prepares a method that contains bytecode referencing it.
>>
> 
> I'm unclear on the specification here. I believe the Java spec's policy
> is to be lazy and being eager will cause classes to be initialised in
> the wrong order. I believe this will cause classpath to initialise
> incorrectly. However, I think this dependence on loading order is
> hazardous. It should at least be kept to a minimum.


You are right;  I was thinking about "linking".  Eager linking is allowed based 
on section 2.17.1 of the JVM spec (2nd ed.).  On page 47, you can read:

"The resolution step is optional at the time of initial linkage..."

On the other hand, 2.17.4 specifies clearly (as you stated) that initialization 
happens "immediately" before certain things.

I'll have to double-check my VM semantics there.

>>This is not that "wrong", as long as Runtime is in a good enough state.
>>Often, initialization is simply setting variables that are not used by
>>the "early" executed method (here: loadLibrary).
>>
> 
> I have subsequently found that Runtime isn't in a good enough state. The
> patch fixes this problem. My restriction is too strict, I will remove it
> when I have a chance to hack at a substantial subsystem of my VM.
> 


I know the feeling.  This is what I am in the process of finishing...

> [snip]
> 
> Sorry, I'm working late and need to get some tea. I'll reply to anything
> else tommorow. Sleep well.


Have a good night!


Etienne
-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] Off topic (probably)

[Ian R. <ir...@cs...>]

Hi Etienne,

> This is NOT off topic.  Any discussion about VM implementation and class
> libraries is welcome!

Cool. I'm always wary of saying there are bugs as quite often it's due
to "assumptions" made by my virtual machine :-) I appreciate the ability
to be able to discuss things regarding class/sablepath very much.

> I see.  I didn't get to insert the properties in my VM, yet, so this is
> a problem.  Breaking the circular dependency is a good solution, but
> we should think about specifying a VM interface to Classpath, with
> the appropriate "bootstrapping"/sequential rules.

As the VM integration guide says there are no bootstrapping
initialisation issues with Classpath 0.02. The alteration to Runtime
fixes the only problem I have found with the latest code so far,
although the problem of assuming path separators are colons remains.

> > My new problems are caused by the way my JVM works. I run class
> > initialisers as soon as a bytecode is executed that references the
> > uninitialised class.
> Mine is even more eager than that; it initializes a class when it
> prepares a method that contains bytecode referencing it.

I'm unclear on the specification here. I believe the Java spec's policy
is to be lazy and being eager will cause classes to be initialised in
the wrong order. I believe this will cause classpath to initialise
incorrectly. However, I think this dependence on loading order is
hazardous. It should at least be kept to a minimum.

> > Unfortunately this set of circumstances
> > happens in class/sablepath:
> >
> > run FileInputStream.<clinit> calls:
> > run System.loadLibrary (java-io) --> wants Runtime.loadLibrary, Runtime
> > uninitialised therefore:
> > run Runtime.<clinit> calls:
> > run Runtime.<init> calls:
> > run File.<clinit> and oh no calls:
> > System.loadLibrary (java-io)
> >
> > Obviously it should be legal in my JVM to execute System.loadLibrary in
> > this way as there are no restrictions placed on the code from the JVM
> > spec. However, it strikes me as wrong to be calling Runtime.loadLibrary
> > when Runtime hasn't been statically initialised.
> 
> This is not that "wrong", as long as Runtime is in a good enough state.
> Often, initialization is simply setting variables that are not used by
> the "early" executed method (here: loadLibrary).

I have subsequently found that Runtime isn't in a good enough state. The
patch fixes this problem. My restriction is too strict, I will remove it
when I have a chance to hack at a substantial subsystem of my VM.

[snip]

Sorry, I'm working late and need to get some tea. I'll reply to anything
else tommorow. Sleep well.

Ian

Re: [Sablevm-developer] More on bootstrapping

[Etienne M. G. <eti...@uq...>]

Ian Rogers wrote:

> Runtime.java is VM dependent file you've pulled in from vm/reference.
> The patch is UNIX dependent and removes the bootstrapping problem. I'm
> unclear how you can remove the UNIX dependence without causing the
> bootstrapping problem. I'll check the file in for now as it is at least
> working on UNIX rather than nothing as before.


One of the reasons I have moved the vm/* classes with the remaining 
classes is that I have this long term objective of specifying even these 
core classes in a VM independent way, as much as possible, leaving as 
little as possible native calls back to the VM to gather VM specific 
information.  I think that this is feasible, at least for "dynamic" 
systems. (Might cause problems for static compilers like GCJ).

The result would be a lean and hopefully well specified VM interface.

I can dream... ;)


Etienne
-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] More on bootstrapping

[Ian R. <ir...@cs...>]

Hi Etienne,

> Just go ahead and check it in.  We certainly don't want system dependant stuff in there.

Runtime.java is VM dependent file you've pulled in from vm/reference.
The patch is UNIX dependent and removes the bootstrapping problem. I'm
unclear how you can remove the UNIX dependence without causing the
bootstrapping problem. I'll check the file in for now as it is at least
working on UNIX rather than nothing as before.

Ian

Re: [Sablevm-developer] Off topic (probably)

[Etienne M. G. <eti...@uq...>]

This is NOT off topic.  Any discussion about VM implementation and class
libraries is welcome!


See below,

On Wed, Sep 19, 2001 at 07:57:05PM +0000, Ian Rogers wrote:
> The actual problem was when I inserted my system properties this lead to
> File.<clinit> being ran which tried to use the properties I was
> inserting. To stop this I stopped Math.<clinit> from being ran by
> altering the definition of Hashtable.hash so it didn't need to use
> Math.abs. I believe I follow the JVM spec for loading classes very
> closely, although I haven't checked this rigorously.

I see.  I didn't get to insert the properties in my VM, yet, so this is
a problem.  Breaking the circular dependency is a good solution, but
we should think about specifying a VM interface to Classpath, with
the appropriate "bootstrapping"/sequential rules.

First, let's try to get the thing up an running, though.

> My new problems are caused by the way my JVM works. I run class
> initialisers as soon as a bytecode is executed that references the
> uninitialised class.

Mine is even more eager than that; it initializes a class when it
prepares a method that contains bytecode referencing it.

> I have a restriction that the bytecode that
> references this uninitialised class can't be executed by the static
> initialiser we're about to run.

I think this restriction is too strict.  You should be able to "resume" the
preparation of your bytecode if it gets called recursively, even though
the referenced class hasn't finished initialization.  This should be feasible,
as long as you have a clear separation between "class linking" and
"class inititialization".  I remember being hit by this problem in an early
version of SableVM, where I didn't have this separation.

> Unfortunately this set of circumstances
> happens in class/sablepath:
> 
> run FileInputStream.<clinit> calls:
> run System.loadLibrary (java-io) --> wants Runtime.loadLibrary, Runtime
> uninitialised therefore:
> run Runtime.<clinit> calls:
> run Runtime.<init> calls:
> run File.<clinit> and oh no calls:
> System.loadLibrary (java-io)
> 
> Obviously it should be legal in my JVM to execute System.loadLibrary in
> this way as there are no restrictions placed on the code from the JVM
> spec. However, it strikes me as wrong to be calling Runtime.loadLibrary
> when Runtime hasn't been statically initialised.

This is not that "wrong", as long as Runtime is in a good enough state.
Often, initialization is simply setting variables that are not used by
the "early" executed method (here: loadLibrary).

> The numerous calls to
> System.loadLibrary (java-io) seem excessive to me also (I can see why
> they're made but is there no better way?). Anyhow, I have tried
> pre-loading java/lang/Runtime and java/lang/System and both fail. You
> can't pre-load java/lang/Runtime without java/lang/System setting up the
> system properties. I can't pre-load java/lang/System as it leads to the
> same error as the one listed above.

As I said, we might have to specify a "correct order" to bottstrap those
classes.

> Any ideas before I remove my restriction? TIA. A simpler solution for me
> would be to alter the behaviour of Runtime.<init> .

Ideally, you should try separating linking and initialization, as proposed
above.  I am pretty sure that this might solve your problem (if you are
careful about class creation order).  [I might be wrong: maybe you already
do this; I'm just trying to guess...]

> > I have updated the configure stuff, and merged with recent classpath
> > changes.
> 
> Thanks for the reminder, I've subscribed to the mailing list and I
> believe I'm up-to-date.


Super.  I might run my exctraction script soon (and more or less regularly).

Have fun!

Etienne
-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] More on bootstrapping

[Etienne M. G. <eti...@uq...>]

Hi Ian,

Just go ahead and check it in.  We certainly don't want system dependant stuff in there.

Etienne

On Thu, Sep 20, 2001 at 06:57:54PM +0000, Ian Rogers wrote:
> Hi,
> 
> I'm free to modify java/lang/Runtime all I want as it is a VM specific
> file :-) It seems badly written too as it half uses ':' as a path
> seperator and half uses File.pathSeperatorChar. The System.setProperty
> -> Hashtable.hash -> Math.<clinit> -> System.loadLibrary ->
> Runtime.loadLibrary -> ... bootstrapping problem seems to be resolved by
> modifying Runtime.Runtime too :-) Anyway my modifications are attached
> as a patch. I'll commit them if anyone wants.
> 
> Ta,
> 
> Ian
> Index: sablepath-classes/src/java/lang/Runtime.java
> ===================================================================
> RCS file: /cvsroot/sablevm/sablepath-classes/src/java/lang/Runtime.java,v
> retrieving revision 1.1.1.2
> diff -r1.1.1.2 Runtime.java
> 45a46,47
> > 		char pathSeparatorChar = ':';
> > 
> 55c57
> < 			if(path.charAt(i) == ':')
> ---
> > 			if(path.charAt(i) == pathSeparatorChar)
> 63c65
> < 			int next = path.indexOf(File.pathSeparatorChar,current);
> ---
> > 			int next = path.indexOf(pathSeparatorChar,current);
> 164a167
> > 	    


-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

[Sablevm-developer] More on bootstrapping

[Ian R. <ir...@cs...>]

Hi,

I'm free to modify java/lang/Runtime all I want as it is a VM specific
file :-) It seems badly written too as it half uses ':' as a path
seperator and half uses File.pathSeperatorChar. The System.setProperty
-> Hashtable.hash -> Math.<clinit> -> System.loadLibrary ->
Runtime.loadLibrary -> ... bootstrapping problem seems to be resolved by
modifying Runtime.Runtime too :-) Anyway my modifications are attached
as a patch. I'll commit them if anyone wants.

Ta,

Ian

[Sablevm-developer] Off topic (probably)

[Ian R. <ir...@cs...>]

Hi, hopefully this isn't too off topic and the work will help other
people.

> The initializer circular dependency sequence is described in details in
> the JVM spec.  So, you should simply implement the spec, and check
> that you are getting the expected result.  If not, then there's a bug;-)

The actual problem was when I inserted my system properties this lead to
File.<clinit> being ran which tried to use the properties I was
inserting. To stop this I stopped Math.<clinit> from being ran by
altering the definition of Hashtable.hash so it didn't need to use
Math.abs. I believe I follow the JVM spec for loading classes very
closely, although I haven't checked this rigorously.

My new problems are caused by the way my JVM works. I run class
initialisers as soon as a bytecode is executed that references the
uninitialised class. I have a restriction that the bytecode that
references this uninitialised class can't be executed by the static
initialiser we're about to run. Unfortunately this set of circumstances
happens in class/sablepath:

run FileInputStream.<clinit> calls:
run System.loadLibrary (java-io) --> wants Runtime.loadLibrary, Runtime
uninitialised therefore:
run Runtime.<clinit> calls:
run Runtime.<init> calls:
run File.<clinit> and oh no calls:
System.loadLibrary (java-io)

Obviously it should be legal in my JVM to execute System.loadLibrary in
this way as there are no restrictions placed on the code from the JVM
spec. However, it strikes me as wrong to be calling Runtime.loadLibrary
when Runtime hasn't been statically initialised. The numerous calls to
System.loadLibrary (java-io) seem excessive to me also (I can see why
they're made but is there no better way?). Anyhow, I have tried
pre-loading java/lang/Runtime and java/lang/System and both fail. You
can't pre-load java/lang/Runtime without java/lang/System setting up the
system properties. I can't pre-load java/lang/System as it leads to the
same error as the one listed above.

Any ideas before I remove my restriction? TIA. A simpler solution for me
would be to alter the behaviour of Runtime.<init> .

> I have updated the configure stuff, and merged with recent classpath
> changes.

Thanks for the reminder, I've subscribed to the mailing list and I
believe I'm up-to-date.

Cheers,

Ian Rogers

Re: [Sablevm-developer] New classpath

[Etienne M. G. <eti...@uq...>]

On Tue, Sep 18, 2001 at 07:49:09PM +0000, Ian Rogers wrote:
> I'm finding that now I'm using the newer classpath files I have a
> dependency problem with Hashtable.hash using Math.abs and the
> Math.<clinit> eventually calling back to Hashtable.hash. How can I run
> the class initialisers to avoid this, or is it a genuine bug?

The initializer circular dependency sequence is described in details in
the JVM spec.  So, you should simply implement the spec, and check
that you are getting the expected result.  If not, then there's a bug;-)

Are you subscribed to 
https://lists.sourceforge.net/lists/listinfo/sablevm-commits
?

If not, you should, so that you get notice of my changes to the CVS
repository (as I get notice of your changes).

I have updated the configure stuff, and merged with recent classpath
changes.

Etienne
-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

[Sablevm-developer] New classpath

[Ian R. <ir...@cs...>]

Hi all,

I'm finding that now I'm using the newer classpath files I have a
dependency problem with Hashtable.hash using Math.abs and the
Math.<clinit> eventually calling back to Hashtable.hash. How can I run
the class initialisers to avoid this, or is it a genuine bug?

TIA,

Ian