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