[concurrency-interest] DirectByteBuffers and reachabilityFence

Vitaly Davidovich vitalyd at gmail.com
Tue Dec 8 14:17:01 EST 2015


>
> 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?? :) So now I'm going to write to dummy fields? And what are
you going to do with it in a finalizer? And of course, a Sufficiently Smart
Compiler could detect (theoretically, of course :)) that this is all just
dummy ops and remove them.

Yes, more or less.  It's happened in the past, and it'll continue
> to happen.  To begin with people didn't much have to worry about
> subtleties to do with finalization and lifetimes, and were bitten
> by it, and fixed their code.


In that case, please let me know if this ever happens, hopefully on a
public mailing list that I can follow along.

In my opinion, the current lack of optimization (accidental or not) should
be somehow encoded/made intentional.  Perhaps treat Unsafe::anything() as a
full compiler optimization fence, if it's not already.  At least don't
break existing code.  For Alexandre's SimpleBuffer version that broke and
breaks today, require them to use reachabilityFence.  This, or something
along these lines, is the pragmatic way to address this.


On Tue, Dec 8, 2015 at 2:03 PM, Andrew Haley <aph at redhat.com> wrote:

> On 12/08/2015 06:28 PM, Vitaly Davidovich wrote:
> >>
> >> This warning about object lifetimes and finalizers is part of the
> >> now-twenty-year-old Java Language Specification.  One would hope that
> >> people have had time to get used to it and its implications.
> >
> > We're going in circles now.  Let me just ask you this -- do you
> > think Oracle would ship a JDK version where code, following the
> > model of DBB, now breaks?
>
> Absolutely, yes.  We already know that very similar code breaks.
>
> > The problem is that there was no way to achieve the desired lifetime
> > guarantees with today's and all prior JDK versions.
>
> 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.
>
> > Why was DBB released then if it's full of subtle gotchas? What are
> > you going to say to users whose code will break, and it will break
> > subtly under particular optimization/code shape scenarios? That they
> > should've followed the 20+ yr old JLS spec, and now that
> > reachabilityFence is out, they should sweep all their code and their
> > 3rd party deps to ensure these subtle lifetimes issues are fixed?
>
> Yes, more or less.  It's happened in the past, and it'll continue
> to happen.  To begin with people didn't much have to worry about
> subtleties to do with finalization and lifetimes, and were bitten
> by it, and fixed their code.
>
> Andrew.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151208/323e65a2/attachment.html>


More information about the Concurrency-interest mailing list