Bootstrap sequence and core classes

[Mark Wielaard]

Hi,

I am trying to figure out why/how the bootstrap sequence is working and
how it is special/needed.

In java/lang/Object.java we have to following:

/**
 * Load in all native methods in the java.lang package. Note that this
 * call is actually a no-op, since it triggers the class initialization
 * of System, which loads the same library; but it is necessary to start
 * the System class initialization for the bootstrap sequence to work.
 */
static
{
  if (Configuration.INIT_LOAD_LIBRARY)
    System.loadLibrary("javalang");
}

And in vm/reference/java/lang/Runtime.java the following comment:

 *
 * No matter what class you start initialization with, it defers to the
 * superclass, therefore Object.<clinit> will be the first Java code
 * executed. From there, the bootstrap sequence, up to the point that
 * native libraries are loaded (as of March 24, when I traced this
 * manually) is as follows:
 *
 * Object.<clinit> uses a String literal, possibly triggering 
 * initialization
 *  String.<clinit> calls WeakHashMap.<init>, triggering initialization
 *   AbstractMap, WeakHashMap, WeakHashMap$1 have no dependencies
 *  String.<clinit> calls CaseInsensitiveComparator.<init>, triggering
 *      initialization
 *   CaseInsensitiveComparator has no dependencies
 * Object.<clinit> calls System.loadLibrary, triggering initialization
 *  System.<clinit> calls System.loadLibrary
 *  System.loadLibrary calls Runtime.getRuntime, triggering 
 *    initialization
 *   Runtime.<clinit> calls Properties.<init>, triggering initialization
 *    Dictionary, Hashtable, and Properties have no dependencies
 *   Runtime.<clinit> calls insertSystemProperties; the VM must make 
 *    sure that there are not any harmful dependencies
 *   Runtime.<clinit> calls Runtime.<init>
 *    Runtime.<init> calls StringTokenizer.<init>, triggering
 *    initialization
 *     StringTokenizer has no dependencies
 *  System.loadLibrary calls Runtime.loadLibrary
 *   Runtime.loadLibrary should be able to load the library, although it
 *       will probably set off another string of initializations from
 *       ClassLoader first

How/Why is it important for VM writers that all this initialization
happens during loading of java.lang.Object? Wouldn't it make more sense
if they happen when those classes are actually used? Would that make
live of the VM writers easier or harder?

The static code block in Object (<clinit>) is only there because we have
our own JNI implementation of Object.getClass(). But I think that
normally a VM would special case that call anyway so I would like to
move that call to VMObject.

Comments? Ideas? Insights?

Cheers,

Mark