> 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
-- ============================================= AntiSpamString: nix flubber now ============================================================================= Dave Detlefs http://www.sunlabs.com/people/detlefs/ Sun Microsystems Laboratories email@example.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