[concurrency-interest] DirectByteBuffers and reachabilityFence

Vitaly Davidovich vitalyd at gmail.com
Wed Dec 9 15:52:44 EST 2015

sent from my phone
On Dec 9, 2015 3:50 PM, "Chris Vest" <mr.chrisvest at gmail.com> wrote:
> Even non-volatile writes can be scalability bottle-necks due to cache
sloshing, even if you writing the same value every time.

Yup, this is just "fancy" false sharing.

> We have a Page concept in Neo4j that, like DBB, has a raw pointer in a
long field. However, we have too many of these objects for them to override
finalize() - the associated companion objects would take up too much heap
space - so they instead all reference a single object that when finalised
will release all the native memory. Therefor special rules for objects with
finalisers won't work for us. We also pull the native pointers out of these
page objects, when working with the memory, because this is used in some of
our hottest code and every indirection counts. So making instance methods
keep the instance alive would only work because those places incidentally
also have field references to the page objects.
> Our code works because we need to guard the memory accesses with locks on
the page objects, which keeps them alive. However, I wouldn't be surprised
to hear about uses for fast explicit reachability fences.
> Chris
> > On 9. dec. 2015, at 20.03, Andrew Haley <aph at redhat.com> wrote:
> >
> > On 12/09/2015 06:52 PM, Vitaly Davidovich wrote:
> >>>
> >>> 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?
> >
> > In the finalizer.  The idea is that you keep a counter in the
> > object and then write it to a global when finalized.  I don't
> > think this can be done much more cheaply without changes to
> > the compiler, and it's certainly much cheaper than the current
> > implementation of reachabilityFence.
> >
> > Andrew.
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151209/5b2f8ee1/attachment-0001.html>

More information about the Concurrency-interest mailing list