JDK-7158682 : G1: Handle leak when running nsk.sysdict tests
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs23
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-04-03
  • Updated: 2013-09-18
  • Resolved: 2012-06-02
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 7 JDK 8 Other
7u40Fixed 8Fixed hs24Fixed
Related Reports
Relates :  
JDK-6976060 - G1: humongous object allocations should initiate marking cycles when necessary
Relates :  
JDK-7147724 - G1: hang in SurrogateLockerThread::manipulatePLL
Description
When running promotion testing with -XX:+UseG1GC the 32 bit VM crashes with:
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 32756 bytes for ChunkPool::allocate

Looking at the pmap of the crashing process it has filled its address space with 2048k blocks of memory, so I suspected that some thread has been leaking handles.

Test names:
nsk/sysdict/vm/stress/chain/chain008
nsk/sysdict/vm/stress/btree/btree008
nsk/sysdict/vm/stress/btree/btree010

UTE rerun cmd:
ute -jdk $my_jdk -testlist nsk.sysdict.testlist -test $test_name -vmopts "-server -Xmixed -XX:+UseG1GC"
(may need a few attempts)

I built a modified VM that prints how many handles each thread has allocated in the hs_err file thread list and it looks like one of the test's worker threads had allocated 734677070 handles.

When the faulty condition is triggered the VM's virtual memory usage grows rapidly and leads to native-oom, so it does not appear to be a slow leak but rather a weird condition or loop that the VM gets caught in.
Comments
Verified JDK:1.7.0_40 b27 HS:24.0 b48
06-06-2013
EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c52a6a39546c
29-06-2012
EVALUATION Changeset: c52a6a39546c Author: johnc Date: 2012-05-30 10:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/c52a6a39546c 7158682: G1: Handle leak when running nsk.sysdict tests Summary: Place HandleMarks in the code that allocates handles for the pending list lock so that the handles are freed and multiple, unsuccessful, attempts to schedule a GC do not cause an OOM. Reviewed-by: brutisso ! src/share/vm/oops/instanceRefKlass.cpp
31-05-2012
EVALUATION The out of memory is caused by a combination of the issues that caused 7147724 and not freeing handles after scheduling a succuessful initial mark pause. The issues that caused 7147724 could cause a thread that was attempting to schedule an initial mark pause (as part of a humongous object allocation) to spin and retry the GC indefinitely. During each GC attempt, the GC VM operation allocates a handle to hold the pending list lock. On the GC call path there are no handle marks to free these handles. As a result they are retained and eventually the system runs out of C - heap.
25-04-2012
SUGGESTED FIX The various fixes for 7147724 solve the potential indefinite spinning issue (which was the main reason for the memory failure) and reduces the number of times the GC is retried. There are still some circumstances where we retry the GC mutiple times. Each time the GC is attempted - a handle is allocated. We need to add HandleMark's around the code that retries the GC so that any handles allocated during the GC attempts are freed.
25-04-2012