[concurrency-interest] DirectByteBuffers and reachabilityFence

Chris Vest mr.chrisvest at gmail.com
Wed Dec 9 15:50:09 EST 2015


Even non-volatile writes can be scalability bottle-necks due to cache sloshing, even if you writing the same value every time.

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



More information about the Concurrency-interest mailing list