United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6697534 Premature GC and invalid lgrp selection with NUMA-aware allocator.
JDK-6697534 : Premature GC and invalid lgrp selection with NUMA-aware allocator.

Details
Type:
Bug
Submit Date:
2008-05-05
Status:
Resolved
Updated Date:
2010-04-03
Project Name:
JDK
Resolved Date:
2008-05-21
Component:
hotspot
OS:
generic
Sub-Component:
gc
CPU:
generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
hs13 (b01)

Related Reports
Backport:
Backport:

Sub Tasks

Description
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.

                                    

Comments
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.
                                     
2008-05-05
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.
                                     
2008-05-06



Hardware and Software, Engineered to Work Together