harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: [drlvm][gcv5] finalizer design
Date Tue, 19 Dec 2006 04:32:06 GMT
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

View raw message