Re: Array marking

[Corey Minyard <minyard at acm dot org>]

"Boehm, Hans" <hans_boehm@hp.com> writes:
> Do we know that if a class becomes unreachable and its loader is
> unreachable, we can't still be executing a static method in the class?  If
> not, then unloading the .so is not safe.

This is not insurmountable.  When a static method was called, the
compiler could throw a reference to the class onto the stack as part
of the call sequence or part of the method initialization.  This would
add some overhead, but not a lot, and only for static methods.

> There are probably several other safety issues with unloading libraries.
> Another one:
> 
> Since Java has unordered finalizers, is there any reason to expect class
> finalization to wait until all instances of the class have been finalized?
> The garbage collector currently does not ensure that, unless libgcj does
> something special to do so.  (And I'm not sure what it could do.)  The spec
> seems unclear about whether it should.  (Since I personally think unordered
> finalization is a bad idea, I'm the wrong person to speculate what it should
> say.)

This is a pain.  I can think of a kludgy way to do it.  Keep a static
reference to the class structure and a counter.  When you allocate an
object of the class (or any subclass), increment the value.  When one
is finalized, decrement it.  When the number of references to the
class structure reaches zero, null the reference.  Ordered finalizers
might be better, but they have their own problems.  If you have a
circular reference situation, such as a pointer in the class data
somewhere to an object of that class, how will the collector know the
finalization order?  It seems like it would be better to be able to
tell the collector some sort of explicit finalization order.  The
counter method I mentioned above might work.

> I would personally avoid calling dlclose() if at all possible.  There are
> too many ways it can result in breakage.  In addition to everything else, it
> currently breaks the incremental collector, since some of those data
> segments you're unmapping might already have been pushed onto the mark
> stack.

Mutexes around dlopen() and dlclose() and the GC scan of library's
static data would be a very good idea.  If I remember correctly from
looking at the collector, it is not safe to call dlopen() right now
either.

Corey