[concurrency-interest] DirectByteBuffers and reachabilityFence

Vitaly Davidovich vitalyd at gmail.com
Tue Dec 8 13:48:58 EST 2015


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


I missed this part.  For concurrent code, how about the fact that volatile
writes in a constructor are effectively treated like final field writes,
even though current JMM does not mandate that? Last I heard, a future JMM
revision will make it such that existing behavior is actually spec'd simply
because lots of existing code relies on it and would break, subtly, if that
were to change.

On Tue, Dec 8, 2015 at 1:28 PM, Vitaly Davidovich <vitalyd at gmail.com> 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? 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/77004fcd/attachment.html>


More information about the Concurrency-interest mailing list