Re: Query on stacktrace management logic

[Chris Gray]

On Saturday 13 March 2004 10:13, Patrik Reali wrote:
> --On Sonntag, 7. März 2004 16:02 +0100 Chris Gray <address@hidden>
>
> wrote:
> > On Thursday 04 March 2004 09:01, Jeroen Frijters wrote:
> >> David Holmes wrote:
> >> > class Class is the first class that must be initialized [...]
> >>
> >> Given the wide variety of VMs that use Classpath, I'd be careful with
> >> statements like these. For almost every such assumption there will be a
> >> VM for which it isn't true.
> >
> > Amen.  Wonka [doesn't use Classbath [yet], but] currently loads five
> > other  classes before java.lang.Class; java.lang.Object,
> > java.lang.Cloneable,  java.lang.Serializable, java.lang.Throwable, and
> > the mysterious "array" class.
>
> You don't need java.lang.String from the beginning?

No.  Our java.lang.String is just a wrapper for a w_string, and the VM uses 
w_string's internally: e.g. a Utf8 Constant is stored as a pointer to a 
w_string.  So java.lang.String currently gets loaded a bit later, as part of 
the "core-classes.in" code.  (This code also generates a global variable(!) 
called clazzString, so that native code can very easily generate instances of 
String, etc.).

> Jaos is more exigent:
> * java.lang.Object
> * java.lang.String (also initialized)
> * java.lang.RuntimeException
> * java.lang.NullPointerException
> * java.lang.ClassCastException
> * java.lang.ArrayOutOfBoundariesException
> * java.lang.OutOfMemoryException
> * java.io.IOException
> * java.lang.AbstractMethodException
> * java.lang.Throwable (also initialized)
> * java.lang.StackTraceElement (also initialized)
> * java.lang.VMThrowable (also initialized)
> * java.lang.Thread (also initialized)
> * java.lang.ThreadGroup (also initialized)
> * java.lang.System (also initialized)
>
> And obviously, many other follow implicitly when a class is initialized.

We also had rather a long list in the past, but the code was so ugly and so 
fragile that I set about reducing it. I prefer to keep special-case code to a 
minimum.

> You may ask why so many classes? Well, there are mainly two reasons. First,
> I try to use as much java code as possible (I'm lazy), thus parts of the
> JVM rely on the code in the libraries. A beautiful example are threads,
> which rely on the Runnable interface: during the first implementation of
> Jaos, the Oberon language didn't have interfaces, thus the threads where
> started by invoking the Java code in java.lang.Thread; only later I did
> integrate Jaos interface support in the Oberon Kernel and added them to the
> language :-) . Of course, some functions must be duplicated for bootstrap
> purposes, because they are needed before they become available.

Yes, I like using Java code too. :) Currently we hack like hell to wrap up 
the first native thread in a java.lang.Thread, but the rest is fairly clean.  
This stuff will probably get a going-over soon when I do some work on JNI 
Activation, and I will be looking to use more Java not less.

BTW there is another reason for "duplicate" code during bootstrap: you are 
often dealing with a more restricted case, and the execution time is 
reflected directly in the startup time for the VM.  Initial class loading is 
a case in point.

> Second, the exceptions are handled by Oberon's exception handler, which is
> not able to load classes. All Exceptions that are generated by the compiler
> or the CPU as interrupts must be already available in Throwable. And
> obviously Throwable, StackTraceElement, and VMThrowable.

We also used to pre-load all exception classes, once upon a time.  But it was 
a helluva lot of stuff to be pre-loading, so now we only do it for a very few 
- basically the ones which can be thrown by the execution engine itself.  So 
if the system class loader throws e.g. a FileNotFoundException we load that 
on the spot; if it also can't find FileNotFoundException.class then we just 
crash. :)

What do you do if a class loaded by a user-defined class loader throws an 
exception which also has to be loaded by that user-defined class loader?

Best wishes

-- 
Chris Gray                                  /k/ Embedded Java Solutions
Embedded & Mobile Java, OSGi              http://www.kiffer.be/k/
address@hidden                                      +32 3 216 0369