[Carefully dodging the hard questions:]
Dave Detlefs wrote:
> 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?)
It would also require a proof that the thread holds no locks.
And even then, I suspect it would break some code. What if the finalizer
waits on a condition variable (e.g. because something else has to finish
first), but it now ends up running in the thread that was supposed to
call notify()? Or you can think of transitive dependencies that are
similar, but the finalizer just needs a lock. Technically this is now
a client bug. But I think I'd rather see that part of the spec continue
to go unenforced. Logically finalizers should run in their own thread.
Otherwise the deadlock issues get pretty hairy.
(The fact that there's generally a finite pool of such threads already
complicates matters more than I'd like.)
>
> 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.
Hans
-------------------------------
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