Re: classpath initialization

[Chris Gray]

For comparison, Wonka's explicit class initialisation looks something like 
this:
  **  1) load class java/lang/Object.
  **  2) load java/lang/Cloneable, java/lang/Serializable, 
java/lang/Throwable.
  **  3) create clazz_Array. clazz_Array acts like clazzObject but has
  **     a modified method table and a modified interfaces table.
  **     It overrides the clone method of java/lang/Object and adds two
  **     new interfaces: Cloneable and Serializable.
  **     (We need to do this before any subclasses of Throwable are loaded,
  **     in order to ensure that they are marked CLAZZ_IS_THROWABLE).
  **  4) load java/lang/Class, java/lang/ClassLoader, java/lang/Thread,
  **     java/lang/ThreadGroup, and java/lang/ref/Reference.
  **  5) load all the classes mentioned in core-classes.in.
  **  6) For each primitive class xxx, create:
  **       -An instance Class_xxx of class java/lang/Class, linked to
  **        a w_Clazz structure (clazz_xxx).
  **        The name associated with the Class instance is "xxx.class".
  **       -Entries in the array atype2clazz[], which is indexed by P_xxx.

Step 5) is needed because we need to create explicit relationships between C 
and Java constructs for quite a large number of classes, which Patrik doesn't 
need to do because he's using Oberon. I guess that's also why he doesn't need 
to explicitly load ClassLoader; we need to do that because of all the 
behind-the-scenes stuff needed to implement class loading according to the 
JVM spec.

Best wishes

Chris


On Monday 20 October 2003 22:03, Patrik Reali wrote:
> Hi!
>
> Initializing a JVM is quite a complicated thing. Many problems depend on
> which class you first initialize, because this could cause unexpected
> dependecies to pop up.
>
> Jaos doesn't suffer from the problem you descrive, because it doesn't use
> the external libraries or JNI: Oberon is rather close to Java, and the
> objects can be directly accessed from both languages without fear of
> breaking the type system or confusing the garbage collector.
>
> I also had my share of problems with the system properties, because they
> are hard-coded in the libraries and I didn't realize it at once.
> Furthermore, the properties and java.io assume an unix-like filesystem,
> which Oberon doesn't have: we don't have directories, only mounts.
>
> In Jaos, I explicitely initialize a few classes during bootstrap (this are
> only the explicit calls, other classes may be automatically initialized as
> side effect, and in fact about 80 are!). This code relies on classpath 0.5
> (I'm not through updating yet).
>
> 1. String
> 2. Throwable
> 3. StackTraceElement
> 4. VMThrowable
> 5. Thread
> 6. ThreadGroup
> 7. System
>
> This may look strange, but....
>
> 1. String is implicitely used everywhere, because the string constants are
> instances of this class; according to the spec, allocating an instance of a
> class causes the class to be initialized. (I could avoid this, but then I
> would have to protect every access to the string methods with a check to
> launch initialization; Strings are already slow enough in Jaos).
>
> 2. Throwable / StackTraceElement / VMThrowable: I must allocate them when
> the VM is launched: loading them on-demand (at the first exception) is
> already too late, because the VM is already processing an exception (in
> Oberon this is done with a software interrupt) and loading reads from the
> disc (causing more interrupts), but the kernel doesn't allow to interrupt
> handler to cause other interrupts.
>
> 3. Thread / ThreadGroup must be initialized, because every java program is
> executed in a java thread; Jaos creates such a thread for the execution of
> a java program.
>
> This remarks (in particular 2 and 3) are quite Jaos specific.
>
> This won't probably solve your problem, but may give you some insight about
> the various problems encountered during the initialization phase.
>
> -Patrik
> --------
> Patrik Reali
> http://www.reali.ch/~patrik/
> http://www.oberon.ethz.ch/jaos
>
>
> ----- Original Message -----
> From: "Joseph Wenninger" <address@hidden>
> To: <address@hidden>
> Sent: Tuesday, October 14, 2003 9:33 PM
> Subject: classpath initialization
>
> > Hi
> >
> > I'm trying to use an unmodified classpath (0.06). I already have
> > something working with a modified one.
> >
> > My problem is that the call stack during initialization of the System
> > class I looks something like
> >
> > LOG:  called: java/lang/System.<clinit>()V()
> > LOG:   called:
> > java/lang/System.loadLibrary(Ljava/lang/String;)V(405c8488)
> > LOG:     called: java/lang/Runtime.getRuntime()Ljava/lang/Runtime;()
> > LOG:     finished:
> > java/lang/Runtime.getRuntime()Ljava/lang/Runtime;->0x8420fd8
> > LOG:     called:
> > java/lang/Runtime.loadLibrary(Ljava/lang/String;)V(8420fd8, 405c8488)
> > LOG:     called:
> > java/lang/VMSecurityManager.currentClassLoader()Ljava/lang/ClassLoader;()
> > LOG:     called: java/lang/ClassLoader.<clinit>()V()
> > LOG: compiler_addinitclass: java/lang/VMClassLoader
> > LOG:     called:
> > java/lang/VMClassLoader.getSystemClassLoader()Ljava/lang/ClassLoader;()
> > LOG:     called:
>
> java/lang/System.getProperty(Ljava/lang/String;Ljava/lang/String;)Ljava/lan
>g /String;(405cb500, 405cb578)
>
> > ()V<i
> >
> > The last line causes an exception, since the static member properties
> > isn't initialized yet. Did anybody else encounter such a problem ? I'm
> > not sure if that it is a vm bug or a compiler problem or something that
> > I miss
> >
> > Kind regards
> > Joseph Wenninger
> >
> >
> >
> > _______________________________________________
> > Classpath mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/classpath
>
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/classpath

-- 
Chris Gray                                /k/ Embedded Java Solutions
Embedded & Mobile Java, OSGi              http://www.kiffer.be/k/
address@hidden                      +32 477 599 703