Bill and Jeremy --
I'm worried a little about the epoch formulation for finalization.
At the risk of giving away an idea I want to work on :-, consider an
escape analysis that identifies a non-escaping object of a class that
has a finalizer. It might be very useful to generate code to put that
object directly on the finalizer queue when it becomes (semantically)
unreachable -- you might get much prompter finalization. At least at
first glance, it now seems a little bit difficult to identify the
epoch: I imagine your intuition was that even a concurrent collector
would have a phase structure whose iterations would map to epochs.
Here, the intuition is at least much less clear.
Maybe an out that saves your formulation is the synchronization
required to put objects on the finalizer queue: these are global sync
points that could maybe be made to correspond to epochs? But I hope
that the particular current structure of the finalizer implementation
doesn't become part of the semantics. It would be nice if in the
situation I described, the compiler could generate code to have the
mutator thread execute the finalizer itself (this might require a
proof that it will throw now exceptions, I guess?)
Collectors with thread-local heaps raise similar issues: some objects
would be identified as unreachable without requiring any global
synchronization.
With these possible exceptoin, I think the formalism you describe maps
onto all concurrent collectors I know about.
I hope this is helpful...
-- ============================================= AntiSpamString: nix flubber now ============================================================================= Dave Detlefs http://www.sunlabs.com/people/detlefs/ Sun Microsystems Laboratories david.detlefs@sun.com 1 Network Drive, Burlington, MA 01803-0902 (781)-442-0841------------------------------- JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:06 EDT