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/