[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Query on stacktrace management logic
From: |
Chris Gray |
Subject: |
Re: Query on stacktrace management logic |
Date: |
Sat, 13 Mar 2004 12:00:33 +0100 |
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
- Re: Query on stacktrace management logic, (continued)
RE: Query on stacktrace management logic, Jeroen Frijters, 2004/03/06
RE: Query on stacktrace management logic, Robert Lougher, 2004/03/07
RE: Query on stacktrace management logic, Jeroen Frijters, 2004/03/10
RE: Query on stacktrace management logic, Jeroen Frijters, 2004/03/12
RE: Query on stacktrace management logic, Jeroen Frijters, 2004/03/12