early class GC?

[Jeff Sturm]

I'm debugging a problem in which interpreted classes appear to be
prematurely collected (the constant pool is overwritten, first in
reclaim).

However I haven't successfully reproduced the problem on x86, and don't
have a good testcase.  Meanwhile I'm struggling to understand the
intent of the libgcj classloader implementation, and I'm be somewhat
surprised if there is a problem and it hasn't been reported yet.  None of
this code is exactly new, after all.

How do we guarantee that live classes are marked by GC?  A class must be
live if either any live instances exist or its classloader is live.
However gnu.gcj.runtime.VMClassLoader doesn't maintain a strong reference
to each loaded class (as it probably should).

Instead we have the loaded_classes table.  Each loaded class (compiled
or not) is hashed into this table.  But only the head of each hash chain
is marked by GC, right?  The GC won't follow the klass->next pointer due
to the use of a procedure descriptor.  (It would if it operated purely
conservatively.)

So my hunch is that if two interpreted classes hash to the same chain, one
will be vulnerable to premature collection.  I suppose one could create a
testcase by loading two classes of the same name, e.g.:

a) define a custom classloader
b) create two or more instances
c) invoke defineClass("foo") on each instance
d) force a collection

in which "foo" has a <clinit> method that stores an instance of itself,
and has a finalizer.  I'll try this later.  (Apologies for thinking this
through as I type).

Jeff