gcj-compiled jigsaw is running

[Jeff Sturm]

On Thu, 3 May 2001, Cedric Berger wrote:
> - Yes, class$ points to a per-class/classloader heap object

Well, consider that class$ is a global data symbol and cannot be
modified.  You'd have to allocate this object during library
initialization, I think.

> Maybee some of the static content could be moved to the heap?

I'd once considered a model based on gcj in which static methods and
fields would be non-virtual members of a class derived from
java.lang.Class whose instances are allocated on the heap.  They
could be created from some kind of static protoclass, containing the
vtables, metadata and field initializers constructed by the compiler.

Without any static class references, these could be allocated on demand
and linked (resolved) upon class initialization.  By allowing unresolved
classes to be loaded, some incomplete packages that now cause link errors
in gcj could be usable.  Link failures would result in a runtime
exception, as they do in normal Java.  A compiled class could even derive
from bytecode.

There are a few more details.  My goal was to be compatible with both
Java and C++.  But I couldn't think of a way to keep CNI without
modification.  So it amounted to yet another class linking/loading model,
sort of a hybrid between compiled (CNI) and the interpreter but different
than each.  It'd be quite a divergence from gcj's architecture, but
interesting nonetheless.

> - the finalizer method of the classloader object dlclose all its libraries

A library can contain one or more classes, and be mapped by one or more
classloaders.  But yes, if all the bookkeeping is properly done they could
eventually be dlclosed.

Given the way gcj works today, it'd be a *lot* of work.

Jeff