From: Godmar Back (gback@marker.cs.utah.edu)
Date: Thu Dec 17 1998 - 02:27:38 EST
I tied all the loose ends together and implemented class garbage
collection. Plus, I added walk methods for methods and fields to
increase overall gc preciseness and speed.
Some notes:
Classes not loaded by a classloader are anchored and not subject to
garbage collection.
I added a debugging option NOCLASSGC which anchors all
newly created class objects, thereby essentially creating the
situation we've had so far: all class objects pinned down and no
class gc.
I added a debugging option FINALIZE which is useful to debug if
things start floating: it shows when certain allocation types
are about to be freed by inserting a finalizer for them.
Class gc is "automatic"; there is no finalizer for class objects
at this time. The only datastructure that must be cleaned up
is the class entry pool. This is done in a quasi-finalizer for
the classloader that loaded the classes. Quasi-finalizer is
the term I just coined for Alexandre's idea of associating a
private static object of an anonymous private class for purposes
of finalization.
The finalizer itself is a function in classMethod.c that removes
all entries belonging to that classloader from the class entry pool.
I added a debugging option CLASSGC to show when classloaders are
reclaimed and class entries removed.
The fact that classes do not have a finalizer means that all things
to which they refer must be subject to gc as well. For this reason,
I replaced the gc_layout with a collectable object.
Note that classes keep their loader alive, while the loader does
not (per se) keep the classes alive. Objects keep the classes
to which they belong alive. This includes ref array objects. (*)
Note further that you might not see Classes unloading as fast
as you'd expect: at first, I thought I had floating garbage,
but then I tracked down references on the stack. Short of
zeroing out all locals (which would be a huge performance hit),
there will be some IMO acceptable delay in the speed in which
classes are gc'd. (If you want to see what I'm talking about,
put println's in the finalizer of ClassGCTest and println
where they're created and create a bunch of them: usually,
only n-2 to n-1 out of n are gc'd). A particular problem are
the 512 byte arrays in the callMethod methods. We might want
to consider alloca allocation here.
This situation will change once we have precise garbage
collection.
Enjoy,
Godmar
-----
(*): hmmm, while I'm writing this, I should check whether
prim array object classes may be loaded through classloaders.
If so, then primitive array objects would have to keep their
classes alive too --- currently, they use walkNull as their
walkFunction.
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:20 EDT