JDK-6697534 : Premature GC and invalid lgrp selection with NUMA-aware allocator.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 7
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-05-05
  • Updated: 2010-04-03
  • Resolved: 2008-05-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u14Fixed 7Fixed hs13Fixed
Premature GC will happen after a call to MutableNUMASpace::ensure_parsibility().
Also on a machine with specific configuration an invalid lgrp selection can occur. For example of arches.sfbay there are two leaf locality group associated with each CPU. But only one of them has memory. The resulting lgrp graph is as follows:
1 (CM) <- 0 (CM) -> 2 (C)
where attributes in parenthesis are C - CPU, M - memory.

With such a configuration Solaris always selects group 0 as a home group for all LWPs.
This situation was not handled correctly and a random leaf group was selected. 
Combined with incorrect tops adjustment random selection can select a chunk with no free space. Should such an event happen during VM initialization a crash occurs.

SUGGESTED FIX The fix adds/changes the following functionality: 1. Tops are not adjusted in ensure_parsibility() 2. Chunks are created only for lgroups that have memory 3. In case if a home lgroup is not a leaf node. A random child node, which has memory is selected.

EVALUATION In MutableNUMASpace::ensure_parsibility() the "tops" all chunks except for the last one are made equal to "ends". If there is no immediate GC, the allocaton will fail. We shouldn't move tops.