Array marking

Mon May 1 10:41:00 GMT 2000

If we want classes to be finalized after all their objects, it should be
possible to get the collector to enforce that. Although this fact is not
well exposed, the collector allows you to control if and how any marking
from otherwise unreachable finalizable objects is handled. Thus you can
tell it to not finalize anything reachable through the class object pointed
to by a finalizable object.
But I'm not at all sure that's the right thing to do: I think it brings up
pretty much all of the issues with cyclic finalization dependencies, etc.,
without getting much of the benefit from real ordered finalization. What if
finalizable class A has a static field, which is a finalizable object of
class A? The more I think about this, it seems to me that leaving class and
object finalizations unordered is more consistent with the rest of the
language.
Finalizable objects are actually somewhat expensive in the collector. They
take additional space, and some additional processing time. You really
don't want to force objects to be finalizable because the class is.
Re: dlopen and dlclose
The dlopen problem is mostly solved in the last two collector alpha
releases, I believe. Unfortunately, the allocator/collector mutex cannot be
held during either, since either causes the dynamic linker to run arbitrary
user initialization/cleanup code, which may allocate. Currently dlopen
disables collections, but not allocation during the call. Dlclose is
unsupported. It could do the same, but that would raise some other annoying
questions: How does the user know when the collector no longer needs the
finalization and mark procedures associated with a dynamic library? What
about other callbacks and possibly data structures registered with the
collector?
My guess is that to use dlclose the collector, you'd need some fairly
restrictive "safe use" rules. I'm not sure whether Java could abide by
those.
Hans
-----Original Message-----
From: Corey Minyard [ mailto:minyard@acm.org ]
Sent: Saturday, April 29, 2000 2:30 PM
To: Boehm, Hans
Cc: 'Bryce McKinlay'; Jeff Sturm; java-discuss@sourceware.cygnus.com
Subject: Re: Array marking
> 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