TLAB and NUMA aware allocator

[Igor Veresov]

On Linux we just hope that the scheduler will leave a thread on the same node, which is what happens in reality. Also, per generational hypothesis we hope that in most cases the data will be already dead when such a migration happens.

And like Jon said it's not an issue on Solaris.

igor

On Sep 27, 2012, at 12:41 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

> Thanks Jon -- that blog entry was useful.
> 
> Vitaly
> 
> On Thu, Sep 27, 2012 at 12:55 AM, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
> Vitaly,
> 
> The current implementation depends on a thread not migrating
> between nodes.  On solaris that naturally happens.  I don't
> remember the details but it's something like Solaris sees that
> a thread XX is executing on node AA and using memory on AA
> so it leaves XX on AA.  On linux I'm guessing (really guessing)
> that there is a way to create an affinity between XX on AA.
> 
> This has all the things I ever knew about it.
> 
> https://blogs.oracle.com/jonthecollector/entry/help_for_the_numa_weary
> 
> Jon
> 
> 
> On 9/26/2012 4:09 PM, Vitaly Davidovich wrote:
> Hi guys,
> 
> If I understand it correctly, the NUMA allocator splits eden into regions
> and tries to ensure that an allocated object is in a region local to the
> mutator thread.  How does this affect tlabs? Specifically, a tlab will be
> handed out to a thread from the current node.  If the java thread then
> migrates to a different node, its tlab is presumably still on the previous
> node, leading to cross-node traffic? Is there a notion of a processor local
> tlab? In that case, access to already allocated objects will take a hit but
> new allocations will not.
> 
> The way I imagine a processor local tlab working is when a thread migrates,
> the previous tlab becomes available for whichever java thread is onproc
> there now - that is, tlab ownership changes.  The migrated thread then
> picks up allocations in the new tlab.
> 
> It can still be a bump the pointer since only one hardware thread can be
> running at a time on the processor.
> 
> Is this or something like it already there? If not, what challenges am I
> overlooking from my high-level view?
> 
> Thanks
> 
> Sent from my phone
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20121001/ebb778b7/attachment.htm>