[This is probably starting to get a little too detailed for this mailing
list ...]
> From: David Detlefs - Sun Microsystems Labs BOS
>
> 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.
It seems to me that this is likely to turn into a pretty special-purpose
optimization. Presumably the malloc call is from native code. You at least
have to know that this particular piece of native code doesn't call back
into Java and acquire Java locks. And you have to know that the Java
code didn't get called from native code holding a malloc lock.
>
> > > 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...
>
I was interpreting "thread-local" as "cannot be accessed by another thread".
That's the right definition for things like synchronization elimination. But
you're right that it may be too strong here.
My intuition is that in both cases (nio and thread-local GC), there's a lot of
simplicity to be gained, and not a lot lost, by always running finalization from
a separate thread. (The malloc buffers would have to wait for another thread
to be scheduled. But that thread could run at high priority, so the wait
shouldn't be that long. If you have enough finalizers that context switch
overhead dominates, then I can see a problem.)
Either way, I'm not sure if any of this interferes
with Bill's and Jeremy's proposal.
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