[concurrency-interest] DirectByteBuffers and reachabilityFence

Andrew Haley aph at redhat.com
Wed Dec 9 13:40:03 EST 2015


On 12/09/2015 02:36 PM, Vitaly Davidovich wrote:
> 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:]

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

I don't think it'd be measurable.  A global volatile write is pretty
cheap.  And I'm sure there are several such writes when queuing a
finalizer.

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

Well, yes.  Indeed it does.

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

Not at all.

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

The global volatile gets hit once, when the object is finalized.  Not
at every access, which is what you'd have to do with a compiler
barrier.  Compiler barriers have a huge effect because they break many
loop optimizations.  That's a no-hoper.

Andrew.


More information about the Concurrency-interest mailing list