[concurrency-interest] DirectByteBuffers and reachabilityFence

Andrew Haley aph at redhat.com
Wed Dec 9 15:08:43 EST 2015


On 12/09/2015 07:30 PM, Gil Tene wrote:
> 
>> On Dec 9, 2015, at 10:40 AM, Andrew Haley <aph at redhat.com> wrote:
>>
>> On 12/09/2015 05:53 PM, Gil Tene wrote:
>>
>>> My take on this would be to change the JLS and JVM spec to state
>>> that 'this' remains reachable until after the last instruction of
>>> every instance method. Period. This would basically equate to
>>> placing an implicit reachability fence at all exist points of every
>>> instance method (I.e. The equivalent of a try...finally). The "nice״
>>> thing about such an implicit reachability fence is that it does not
>>> really defeat any optimizations, as it only serves to extend the
>>> lifetime of an oop (so potentially pressing slightly harder on the
>>> register allocator). IMO this would auto-magically fix lots of
>>> current rarely occurring bugs (like those on DBB, but also in user
>>> code), and prevent many future ones.
>>
>> Mmmm.  That's what I said!
> 
> So we agree. At least for classes with finalizers in them. But since what you said was:
> 
>> … I have in the past argued that methods of classes with finalizers
>> should automagically extend the lifetime of the "this" object.
> 
> And what I am saying is that ALL instance methods should have
> this quality (not just the ones in classes with finalizers). We may still
> have a gap (or maybe that gap is gone now).

Ah, yes we do.

> My point is that this reachability race has nothing (specific) to do with
> finalizers or finalization, and applies just as much to things that cannot
> be easily detectable from a class's qualities (like having a finalizer).
> Therefore any solution that only addresses finalizers seems insufficient.

Possibly so, yes, given that there is nothing special about "this".
I take your point.

What would this do to objects which don't escape?  I presume that
there would be no need to extend their lifetimes, and the usual
"as if" rule would apply.

Andrew.



More information about the Concurrency-interest mailing list