RFR (XXS): 8165153: Crash in rebuild_cpu_to_node_map

Chris Plummer chris.plummer at oracle.com
Wed Sep 7 06:07:23 UTC 2016


Hi David,

Your fix looks fine and at least gets things back to where they were 
before 6515172.

BTW, the man page for numa_allocate_cpumask() says to allocate the 
buffer using numa_node_to_cpus(). It also says to use 
numa_num_possible_cpus() to get the number of CPUs, which could have 
been used to set the size of the cpu_to_node array. I'm not sure why we 
deviated from this, but if the code had been written to use these APIs 
it would have been immune to your 6515172 changes. This might also fix 
the issue with dynamically enabled CPUs. Maybe a followup CR should be 
filed to address this after JDK 9.

cheers,

Chris

On 9/6/16 6:00 PM, David Holmes wrote:
> webrev: http://cr.openjdk.java.net/~dholmes/8165153/webrev/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8165153
>
> The NUMA rebuild_cpu_to_node_map code is intended to map from physical 
> CPU ID's to nodes on a system. To determine how many CPUs there are it 
> uses os::active_processor_count(). That is actually incorrect as it 
> needs to how many CPUs the system has, not how many have been made 
> available to the JVM. This worked** in the past because the 
> active_processor_count() returned the number of online CPUs. However, 
> after the fix for 6515172, it returned the number of available CPUs, 
> as it should.
>
> The fix is to change that code to use processor_count(), which is the 
> number of configured CPUs on the system.
>
> Thanks,
> David
>
> ** The old code would likely also fail if the number of online CPUs 
> dynamically increased after the JVM was started!




More information about the hotspot-runtime-dev mailing list