Re: java.lang.System changes

[Steven Augart]

Archie Cobbs wrote:
> Steven Augart wrote:
>
> > Classpath's java.lang.System was changed yesterday so that
> > initializing that class now depends upon
> > VMClassLoader.getSystemClassLoader() being able to return a working
> > class loader.
> >
> > Unfortunately, Jikes RVM's system class loader is based upon
> > Classpath's java.lang.URLClassLoader.  java.lang.URLClassLoader
> > requires java.lang.URL to be initialized.  And java.lang.URL, in
> > *its* initialization, makes a call to
> > java.lang.System.getProperty().   Which needs java.lang.System to be
> > initialized. 
>
>
> Just curious.. what is the actual problem you're seeing? 

The actual problem I'm seeing is that (after having done some
rearranging of the sequence in which we run static class initializers),
when I start up my VM, I get a nasty stack trace like this:

Exception in thread "Jikes_RVM_Boot_Thread": 
java.lang.ExceptionInInitializerError: Caught exception while invoking the class 
initializer for java.net.URL
        at com.ibm.JikesRVM.VM.runClassInitializer(VM.java:470)
        at com.ibm.JikesRVM.VM.finishBooting(VM.java:242)
        at com.ibm.JikesRVM.VM.boot(VM.java:108)
Caused by: java.lang.NullPointerException
        at java.lang.System.getProperty(System.java:582)
        at java.net.URL.<clinit>(URL.java:201)
        at com.ibm.JikesRVM.VM.runClassInitializer(VM.java:466)
        at com.ibm.JikesRVM.VM.finishBooting(VM.java:242)
        at com.ibm.JikesRVM.VM.boot(VM.java:108)
JikesRVM: exit 113

Whereas, if I move "System" to an earlier place (in Jikes RVM's CVS head,
it's the second class initialized, and the class loaders are set up later),
then I fail when System's class initializer <clinit> calls
VMClassLoader.getSystemClassLoader, which in turn tries to create a
(Jikes RVM) ApplicationClassLoader, a class whose superclasses haven't been
reinitialized yet.  The stack dump looks like this:

   Lcom/ibm/JikesRVM/VM; sysExit(I)V at line 1118
   Lcom/ibm/JikesRVM/classloader/ApplicationClassLoader; 
<init>(Ljava/lang/String;)V at line 59
   Lcom/ibm/JikesRVM/classloader/VM_ClassLoader; 
getApplicationClassLoader()Ljava/lang/ClassLoader; at line 62
   Ljava/lang/VMClassLoader; getSystemClassLoader()Ljava/lang/ClassLoader; at 
line 117
   Ljava/lang/System; <clinit>()V at line 294
   Lcom/ibm/JikesRVM/VM; runClassInitializer(Ljava/lang/String;)V at line 467
   Lcom/ibm/JikesRVM/VM; finishBooting()V at line 237
   Lcom/ibm/JikesRVM/VM; boot()V at line 108


The real problem here is that as part of building its boot image, Jikes
RVM has already run the class initializers for many classes.
Some of those point to data that can't be carried over between
the boot image writing time, and the VM runtime.  They need to be
re-run at boot time.  Re-running those initializers is hard-coded
as part of the boot sequence, including the order in which they need
to be re-run.

> It looks like
> VMClassLoader.getSystemClassLoader() is invoked after System.properties
> is created, so System.getProperty() should work when URL uses it.. ?
> I haven't actually tried this so I'm likely just missing something.

I want to thank you for writing this letter.  It forced me to think
through why this probably works OK on other VMs.  I suppose what happens
with other VMs is that the class initializer for their system/application
class loader is run in the middle of running the class initializer
for java.lang.System.

Inspired by this, I've just tried cobbling together a routine to
"uninitialize" a class so that it will have its initializer run
dynamically, as needed.  This didn't work, for reasons that will probably
be clear in the morning when I look at the issue again.

--Steve Augart

--
Steven Augart

Jikes RVM, a free, open source, Virtual Machine:
http://oss.software.ibm.com/jikesrvm