classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Query on stacktrace management logic


From: Jeroen Frijters
Subject: RE: Query on stacktrace management logic
Date: Mon, 8 Mar 2004 12:33:29 +0100

Chris Gray wrote:
> Oops my bad - I confused initialisation with loading.  Then I 
> see that Wonka actually initialises both ThreadGroup and
> Thread before Class, but OTOH I also know that the
> initialisation of our ThreadGroup and Thread are subject 
> to special restrictions (because at that moment there is no 
> current Thread, and no Class instance can be created).
> So David's statement is probably pretty close to being true
> in a practical sense, as well as a JLS sense.

I don't necessarily agree or disagree, but I think it is important to
keep an open mind about these things. On IKVM, I don't have any of the
usual bootstrapping issues, so static initialization basically just
happens whenever it is needed. For example, here is what my
initialization looks like for "Hello, World!":

C:\>ikvm -Xmethodtrace:clinit -Xtrace:*=off hello
[11:56:26.75996 main] java.lang.System.<clinit>()V
[11:56:26.76998 main] java.lang.Runtime.<clinit>()V
[11:56:26.76998 main] java.lang.VMRuntime.<clinit>()V
[11:56:26.77999 main] java.lang.StringHelper.<clinit>()V
[11:56:26.80002 main] java.io.FileDescriptor.<clinit>()V
[11:56:26.80002 main] java.io.PrintWriter.<clinit>()V
[11:56:26.81004 main] gnu.java.io.EncodingManager.<clinit>()V
[11:56:26.81004 main] java.lang.Class.<clinit>()V
[11:56:26.88014 main] gnu.java.io.decode.Decoder.<clinit>()V
[11:56:26.88014 main] gnu.java.io.decode.Decoder8859_1.<clinit>()V
[11:56:26.90016 main] gnu.java.io.encode.Encoder.<clinit>()V
[11:56:26.90016 main] gnu.java.io.encode.Encoder8859_1.<clinit>()V
[11:56:26.90016 main] java.lang.ClassLoader.<clinit>()V
[11:56:26.95024 main] java.io.File.<clinit>()V
[11:56:26.95024 main] gnu.java.io.PlatformHelper.<clinit>()V
[11:56:26.95024 main] java.lang.Character.<clinit>()V
[11:56:26.95024 main] java.net.URL.<clinit>()V
[11:56:26.96025 main] java.util.Locale.<clinit>()V
[11:56:27.00031 main] java.net.URLClassLoader.<clinit>()V
[11:56:27.00031 main] java.security.Policy.<clinit>()V
[11:56:27.00031 main]
gnu.java.security.provider.DefaultPolicy.<clinit>()V
[11:56:27.01032 main] java.lang.ExceptionHelper.<clinit>()V
[11:56:27.01032 main] java.util.WeakHashMap.<clinit>()V
[11:56:27.02034 main] java.io.FilePermission.<clinit>()V
[11:56:27.05038 main] java.lang.Number.<clinit>()V
[11:56:27.05038 main] java.lang.Integer.<clinit>()V
[11:56:27.19058 main] java.lang.Void.<clinit>()V
Hello, World!
[11:56:27.20060 ] java.lang.Thread.<clinit>()V
[11:56:27.20060 ] java.lang.VMThread.<clinit>()V
[11:56:27.21061 ] java.lang.ThreadGroup.<clinit>()V
[11:56:27.21061 ] java.lang.ThreadLocal.<clinit>()V
[11:56:27.21061 ] java.lang.InheritableThreadLocal.<clinit>()V
[11:56:27.21061 ] java.util.Collections.<clinit>()V

(As an aside, I just noticed the incredibly lame static initializer we
have in Thread (to initialize a field to zero) and the fact that I have
a static initializer in VMRuntime that isn't really needed.)

Now having said all that, I'm certainly not opposed to making the
unknownProtectionDomain initialization in Class lazy. In fact, it looks
like a good optimization.

Regards,
Jeroen




reply via email to

[Prev in Thread] Current Thread [Next in Thread]