ClassLoader initialization in _Jv_RunMain

Tom Tromey tromey@redhat.com
Mon Nov 10 05:26:00 GMT 2003


>>>>> "Bryce" == Bryce McKinlay <bryce@mckinlay.net.nz> writes:

Bryce> The ClassLoader static initializer runs a whole lot of code, and we
Bryce> are running it before (eg) we have attached to the main thread, which
Bryce> is problematic. Removing it doesn't seem to have had any negative
Bryce> effect -
Bryce> presumably ClassLoader would be the only place that refers to
Bryce> VMClassLoader anyway, so VMClassLoader should never get initialized
Bryce> first. Can we remove this?

We can't, since we can get into circular initialization problems.  As
I remember it, the problem I saw was that initializing
gnu.gcj.runtime.VMClassLoader caused ClassLoader to be initialized,
and so forth, but then we'd call into VMClassLoader to load a class,
causing us to reference ClassLoader.systemClassLoader, which hadn't
been set, leading to spurious failures.

I only saw this with a complex example, according to my notes it was
eclipse.  Setting up a precompiled eclipse to test this isn't easy
:-(.  I should have written a small test case, shame on me.

I agree, though, that we shouldn't do this until the first thread is up.
Perhaps we can change how systemClassLoader is set to solve the
bootstrap problem.

I'll back out this patch tonight and build a new eclipse.  Tomorrow
I'll try it out and report back.

Tom



More information about the Java mailing list