[concurrency-interest] DirectByteBuffers and reachabilityFence

Vitaly Davidovich vitalyd at gmail.com
Wed Dec 9 13:52:18 EST 2015


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


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.


Perhaps I misunderstood your global volatile suggestion -- when is it
written to exactly? What's the usage?

Compiler barriers have a huge effect because they break many
> loop optimizations.  That's a no-hoper.


That's true.  That's another reason to intrinsify reachabilityFence()
since, in its current form, it will be exactly like a compiler barrier.


On Wed, Dec 9, 2015 at 1:40 PM, Andrew Haley <aph at redhat.com> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151209/bc71f809/attachment.html>


More information about the Concurrency-interest mailing list