[concurrency-interest] DirectByteBuffers and reachabilityFence

Vitaly Davidovich vitalyd at gmail.com
Wed Dec 9 09:36:21 EST 2015

sent from my phone
On Dec 9, 2015 5:33 AM, "Andrew Haley" <aph at redhat.com> wrote:
> 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."

As many silly suggestions/workarounds as you propose :).

> > 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 take perf hit? No thanks

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

JLS prescribes observable behavior not exact steps.

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

Maybe you missed the "compiler" part.  I'm suggesting a compiler-only
fence.  And I like how you suggested updating a global volatile above but
here a full fence (which isn't what I proposed) is a no-hoper.

> Andrew.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151209/81a0c9d2/attachment.html>

More information about the Concurrency-interest mailing list