[concurrency-interest] DirectByteBuffers and reachabilityFence

Vitaly Davidovich vitalyd at gmail.com
Tue Dec 8 13:28:32 EST 2015


>
> 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? The problem is that there was no way to achieve the desired
lifetime guarantees with today's and all prior JDK versions.  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?

It'll only happen with some user abusing Unsafe.  I know perfectly
> well what would be said!


Didn't we just recently experience the hoopla surrounding Unsafe usage? And
that was "simply" about hiding Unsafe -- now you're going to crash user
code and expect what? Praise? Let's be realistic here and not be dogmatic
about what the spec says.  The spec would be fantastic if behavior was
consistent, predictable, and enforceable/controllable from user code on Day
1.

Again, there's precedent for existing unspec'd behavior either causing
implementations to ensure they don't break the behavior and/or causing the
spec to be updated to match behavior.

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

> On 12/08/2015 04:44 PM, Vitaly Davidovich wrote:
>
> > So your claim is that, generally speaking, if something works a
> > certain (observable) way in interpreter it's not guaranteed to work
> > in same (observable) way with compiled code, except quicker? I find
> > that hard to believe based on various compiler-dev threads I've read
> > over the years, but no point in debating this.
>
> Yes, that is my claim.  It's certainly true in the case of concurrent
> code, which is the subject of this list.  It's certainly true in the
> case of reachability, which is the subject we're discussing.
>
> >> And in that case the answer is, I suspect, that the optimizer doesn't
> >> know that the position field is unused by the finalizer.  If it did
> >> know this, then you'd have early finalization.  As for the other
> >> cases, it's not worth speculating without looking at code.
> >
> > The question is why do the various getters work in the face of early
> > finalization/reclaim given they don't touch internal state? I don't
> > have a good answer for this other than compiler is careful about
> > optimizing around Unsafe operations (it does know about unsafe
> > memory accesses, that I know for sure).
>
> Dunno.  It'd be interesting to try to break a getter and then look at
> the code.
>
> >> I don't see why: it'd require a patch to DBB, but people don't ship
> >> JVMs without a copy of rt.jar (or somesuch) anyway.
> >
> > See my comment about final field treatment as it stands today.  You
> > can patch JDK, but you'll likely break some user code that was
> > "following" DBB as a model.
>
> Indeed.
>
> > Personally, I prefer aggressive optimizations and willing to fix
> > code if I did something wrong, but in this case there was no good
> > way to fix the code prior to writing it.  This is not a spec-wise
> > decision/situation, this is purely practical implications of
> > breaking user code.  This whole thing begs the rhetorical question
> > then -- why was this functionality released given it's rife with
> > lifetime issues?
>
> 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.
>
> > That ship has sailed now, and I'd hate to be the one explaining to
> > users that some optimizer change now segfaults their VM.
>
> It'll only happen with some user abusing Unsafe.  I know perfectly
> well what would be said!
>
> Andrew.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151208/802a2638/attachment.html>


More information about the Concurrency-interest mailing list