United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 7060842 UseNUMA crash with UseHugreTLBFS running SPECjvm2008
7060842 : UseNUMA crash with UseHugreTLBFS running SPECjvm2008

Details
Type:
Bug
Submit Date:
2011-06-29
Status:
Closed
Updated Date:
2011-11-25
Project Name:
JDK
Resolved Date:
2011-09-30
Component:
hotspot
OS:
linux
Sub-Component:
gc
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs22
Fixed Versions:
hs22

Related Reports
Backport:
JDK-2213970 - UseNUMA crash with UseHugreTLBFS running SPECjvm2008
Backport:
JDK-2213577 - UseNUMA crash with UseHugreTLBFS running SPECjvm2008
Relates:
JDK-7124829 - NUMA: memory leak on Linux with large pages
Relates:
JDK-6843484 - os::commit_memory() failures are not handled properly on linux

Sub Tasks

Description
SIGBUS with UseNUMA on Linux with UseHugeTLBFS running SPECjvm2008.

Command line to reproduce:

java -Xmx26g -Xms26g -Xmn22g -XX:+UseParallelOldGC  -XX:+AggressiveOpts -XX:+UseLargePages -XX:FreqInlineSize=650 -XX:+TieredCompilation -XX:+UseNUMA -XX:+UseHugeTLBFS ???jar SPECjvm2008.jar ???ikv compiler.compiler

Choose a heap size close to maximum that can be run on the test system: the
test case starts passing with smaller heap sizes.

Comments
EVALUATION

See main CR
2011-09-12 
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a20e6e447d3d
2011-08-17 
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a20e6e447d3d
2011-08-17 
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/a20e6e447d3d
2011-08-06 
WORK AROUND

The problem can be bypassed by disabling UseAdaptiveSizePolicy.
2011-06-29 
EVALUATION

The issue seems to be in MutableNUMASpace::bias_region, which tries to free memory
(free_memory) by a call to ::madvise(x,x, MADV_DONTNEED).  If the os::free_memory call
in bias_region is replaced with os::commit_memory (which is mmap) as it was done in
earlier versions (free_memory was implemented via mmap previously on Linux), the test
case starts passing.
2011-06-29 
EVALUATION

It seems to me this could be a race for the pages. Like we do madvise(DONTNEED) that uncommits the space, and then after a while the mutator touches this area and at this point there are not pages available in the virtual swap and we die. So, it seens like bug in madvise(DONTNEED) implementation, may be we should just switch back to doing this with mmap.
2011-06-29


Hardware and Software, Engineered to Work Together