sablevm-developer

[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

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] 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] 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] 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] 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/