Re: gcj-compiled jigsaw is running

[Jeff Sturm <jsturm at one-point dot com>]

On Tue, 1 May 2001, Mark Wielaard wrote:
> Yes. But the classloaders can be arranged in a tree.
> Multiple classloaders can have the same parent. If they define the
> same class (name) then for the runtime system they are different
> classes (they don't override each other).

I agree.  Sibling classloaders can load classes of the same name
independent of one another.  (This ought to work in libgcj's interpreter,
though I have doubts a classloader can be garbage collected right now...
since the loaded_classes array is statically allocated and visible to GC.
The whole class cache mechanism is due to be revisited IMHO.)

> But can the "magic" that is done in natClassLoader.cc,
> gnu::gcj::runtime::VMClassLoader::findSystemClass,
> only be done in the system classloader?

I think so.  Otherwise a compiled class could be loaded in two separate
instances, each with its own Class instance and copy of static variables.
But these are created by gcj and bound by the linker.  They can't be
separated, unless you create a copy of the shared library with another
name and dlopen each.

Even if you get around that, there is no way to unload a compiled class,
because the class instance isn't dynamically allocated and cannot be
garbage collected.

> Maybe it is possible to load and link
> symbols from libraries in different "namespaces" (classloaders can be seen
> as different namespaces for classes with the same name).

I'm not quite sure myself.  It doesn't appear to be possible with
the dlopen interface. ELF is probably the most advanced object format
around, but is still somewhat stupid in terms of modern languages (witness
C++ symbol mangling).

> Does anybody know what documentation
> I can read to get up to speed with Unix dynamic library linking?

John Levine's book "Linkers & Loaders" was helpful for me.  He compares
ELF and other popular formats, with even a brief section on Java.

Jeff