From: Godmar Back (gback@cs.utah.edu)
Date: Sun Jan 03 1999 - 18:50:28 EST
I think I got it fixed now. You might want to take a look.
In my opinion, there was no way around destructors for class objects;
the existing finalizer mechanism simply would not have guaranteed that
class objects survive all instances of the class.
Having introduced destructors, we could also use them to tackle the
problems with reattachment that we have with the quasi-finalizers.
Actually, it's not only quasi-finalizers, but also real finalizers such
as String.unintern which causes the problems described in the FAQ.
In our quest to achieve fully precise gc, the following pieces are left
to tackle:
Method.c.bcode.code / c.ncode.ncode_start (BYTECODE/JITCODE (*))
Method.exceptiontable (EXCEPTIONTABLE (*))
Method.ncode (?)
Field.info (?)
Class.constants.data (CONSTANT (*))
Class.dtable (DISPATCHTABLE (*))
(Of course, I omitted the fact that we still scan stacks conservatively.)
The ones with a (?) I don't know yet what they're pointing to, and the ones
with a (*) points to data that is currently walked conservatively.
Why is jitcode walked conservatively? Are gc-able objects embedded in
instructions? If so, which?
I know the constant pool has CONSTANT_ResolvedStrings in it which must
be walked. Is there anything else in there? There may be class objects,
actually.
Why is the dispatchtable walked conservatively? Shouldn't its entries
simply point to entries in the method table, or the method table of a
superclass?
You'll notice that I put destroyClass in classMethod.c. I feel that
walkClass --- and all walk functions, for that matter, should be moved
outside of mem/ as well since the rely more on VM-specifics than on
gc-specifics.
One thing I've been thinking of is restructuring the gc interface such
that the VM could register allocation types as triples
(walkFunction, finalizeFunction, destroyFunction) with the gc subsystem.
The gc subsystem would return a handle that the VM could use for future
allocations. This handle would take the place of `GC_ALLOC_XXX'.
The gc subsystem would export the markObject and a markObjectPrecise
function that could be used to implement the walkMethods.
It could also export walkConservative for convenience.
If I'm not mistaken, this is how many gc packages work. At least those
that allow users to supply their own walk functions.
- Godmar
ps:
On an unrelated note, here is the memory statistics I'm getting for a
long running test that exercises class gc:
Memory statistics:
------------------
object: Nr 118 Mem 3K array: Nr 142 Mem 14K
class: Nr 104 Mem 11K method: Nr 81 Mem 78K
field: Nr 50 Mem 6K static: Nr 31 Mem 1K
dispatch: Nr 88 Mem 25K bytecode: Nr 757 Mem 26K
exception: Nr 45 Mem 1K constant: Nr 83 Mem 46K
utf8const: Nr 1347 Mem 54K interface: Nr 40 Mem 0K
jit: Nr 164 Mem 46K fixed: Nr 3964 Mem 2584K
lock: Nr 60 Mem 2K ref: Nr 1448 Mem 33K
threadCtx: Nr 143 Mem 66K other: Nr 98 Mem 4K
The $64,000 question here is what are the 2.5 MB of fixed data used for?
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:28 EDT