[concurrency-interest] DirectByteBuffers and reachabilityFence

Gil Tene gil at azul.com
Wed Dec 9 14:30:25 EST 2015


> 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).

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.

> One other advantage to doing this
> automagically is that you won't get all these Java devs arguing about
> whether the reachabilityFence really was needed.

+1000.

I'd much prefer a language and JVM spec change, and a conservative
implementation that already applies that change in the meantime. It will
make current code "just work", and save us from a l lot of "your code
is bad, you misunderstood the promises of liveness on 'this', so it's your
fault, and you should fix your code with reachabilityFence" discussions.

Note that the ability to explicitly call reachabilityFence is still needed
elsewhere. probably in the places it was originally envisioned for. So
I'm not advocating for replacing it with implicit behavior, I'm arguing
for implementing both.


> 
> Andrew.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151209/b9284f26/attachment.bin>


More information about the Concurrency-interest mailing list