Turn on UseNUMA by default when prudent

Eric Caspole eric.caspole at amd.com
Tue May 29 21:15:17 UTC 2012


On May 29, 2012, at 3:56 PM, Jesper Wilhelmsson wrote:

> Hi Eric,
>
> As long as this is based on actual data and not just a hunch, I  
> personally think it is a good idea. I don't know if we have any  
> policies about platform specific optimizations like this though.
>
> I have some comments on the code layout and there are a few typos,  
> but I guess this is still a draft so I won't pick on that right now.
>
> One thing I wonder though is in os_linux_x86.cpp:
>
> if (VM_Version::cpu_family() == 0x15 || VM_Version::cpu_family() ==  
> 0x10) {
>
> Is this the only way to identify the proper processor family? It  
> doesn't seem very future proof. How often would you have to change  
> this code to keep it up to date with new hardware?

I will check on future plans but from past experience I would say  
once every 2-3 years or so. Not all families are server parts.


>
> Regards,
> /Jesper
>
>
> On 2012-05-29 20:54, Eric Caspole wrote:
>> Hi Hotspot team,
>>
>> We sometimes notice on multi-socket systems large run to run  
>> variation in some
>> benchmarks which seems to be attributed to bad/unlucky numa  
>> behavior. So we
>> would like to add simple checks to turn on +UseNUMA for AMD  
>> platforms in the
>> right situations; for example, max heap >= 4GB and we detect a  
>> multi-socket
>> system. This should be a useful out-of-box improvement for most  
>> customers
>> since UseParallelGC is the default.
>>
>> For benchmarks with a large heap, it helps give better out-of-box  
>> performance
>> in many cases.
>>
>> Here is my first webrev to turn on NUMA for AMD systems when it is  
>> a numa
>> system and the heap is set >= 4GB.
>>
>> http://cr.openjdk.java.net/~ecaspole/numa_default/
>>
>> Please let me know your thoughts on the merit of doing this and if  
>> it is
>> worthwhile what should be the structure of the change in the  
>> shared/os/cpu
>> specific code.
>>
>> Thanks,
>> Eric
>>
>>
>





More information about the hotspot-gc-dev mailing list