RE: JavaMemoryModel: Another attempt at formalizing finalization; need particular attention from parallel GC people

From: David Detlefs - Sun Microsystems Labs BOS (david.detlefs@sun.com)
Date: Fri Apr 23 2004 - 10:01:25 EDT


Hans --

> It would also require a proof that the thread holds no locks.
> ...
> Logically finalizers should run in their own thread.
> Otherwise the deadlock issues get pretty hairy.

Yes, agreed. I had in mind "we could do this for particularly simple
finalizers", and thought of only one instance of "not particularly
simple"...as you point out, there are several more.

An example you'd like to be able to get is nio byte buffers backed by
malloc'ed regions, to do the "free" in a timely manner.

> > Collectors with thread-local heaps raise similar issues: some objects
> > would be identified as unreachable without requiring any global
> > synchronization.
>
> Right. But if an object is finalizable, and you believe the above
> argument, it's not thread-local. Thus I'd argue we're OK there.

Here I'm not sure we agree yet. I would interpret "thread-local" as
meaning that it's reachability can be decided considering only
references from the current thread as roots -- "thread-local" in the
sense of escape analysis. Maybe I'm saying that it's reachability can
be determined thread-locally, and you're considering whether it's
finalizer can be executed thread-locally -- they're separable
questions...

-- 
============================================= 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