[concurrency-interest] DirectByteBuffers and reachabilityFence

Andrew Haley aph at redhat.com
Wed Dec 9 05:33:11 EST 2015

On 08/12/15 19:17, Vitaly Davidovich wrote:
>> [me:]
>> Absolutely, yes.  We already know that very similar code breaks.
> "Very similar" is slightly different though.
>> Sure there is: write a field (a counter, say) in your methods and read
>> it in the finalizer.  Make sure that you do something with the field
>> in the finalizer to ensure it's not eliminated: a volatile write will
>> do.  This is fully JLS-compliant; reachabilityFence() is just an
>> optimization.
> C'mon, really?? :)

I wonder how many times I'm going to wrote "Absolutely, yes."

> So now I'm going to write to dummy fields? And what are you going to
> do with it in a finalizer?

Update a global volatile.

> And of course, a Sufficiently Smart Compiler could detect
> (theoretically, of course :)) that this is all just dummy ops and
> remove them.

No, it can't.  Because the JLS says so.  IMVHO it'd be much better to
stop trying to guess what a compiler might do and simply write in the
language instead.

> In my opinion, the current lack of optimization (accidental or not)
> should be somehow encoded/made intentional. 

I have in the past argued that methods of classes with finalizers
should automagically extend the lifetime of the "this" object.
However, I was on the losing side, and reachabilityFence() is the
compromise result.  That's okay, really: it solves the practical

> Perhaps treat Unsafe::anything() as a full compiler optimization
> fence, if it's not already.

That one really is a no-hoper.  The idea of NIO ByteBuffers is "as
fast as C" and full fences would be a pretty major regression.


More information about the Concurrency-interest mailing list