Weldon Washburn wrote:
Robin,
If its handy, could you summarize the finalizer/GC interface in Jikes for
us? Also, do you happen to know the design problems in Jikes finalizers?
This would help us get a better understanding of how to design a java-based
finalizer.
MMTk provides an entry point where the VM can place an object on the
finalization candidate list. At the end of every GC, this list is
scanned and objects that have become unreachable are placed on the 'to
be finalized' list (which keeps the objects alive). The VM can request
objects from this list - when we give them to the VM, we no longer keep
them alive.
That's basically it.
While the implementation hasn't been particularly optimized (a
generational collector doesn't have to scan the candidate list after a
minor GC for example), I think the interface is clean and minimal.
My impression is that finalizers were just done because we need them,
rather than because someone had a neat design they wanted to research.
The Finalizer thread within jikes waits on a mutex on the 'to be
finalized' list, requests objects and executes the finalizers using
reflection. When the list is empty, it goes back to waiting. A
production VM would probably want to do something better here (long
running finalizers would be a major problem), but I don't see how or why
the GC would want to be involved.
--
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/
