Re: classpath initialization

[Patrik Reali]

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