Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2225303 | 8 | John Cuthbertson | P3 | Resolved | Fixed | b42 |
JDK-8018245 | 7u45 | John Cuthbertson | P3 | Closed | Fixed | b01 |
JDK-8002543 | 7u40 | John Cuthbertson | P3 | Closed | Fixed | b01 |
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.
# 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.
- backported by
-
JDK-2225303 G1: Handle leak when running nsk.sysdict tests
- Resolved
-
JDK-8002543 G1: Handle leak when running nsk.sysdict tests
- Closed
-
JDK-8002544 G1: Handle leak when running nsk.sysdict tests
- Closed
-
JDK-8018245 G1: Handle leak when running nsk.sysdict tests
- Closed
- relates to
-
JDK-7147724 G1: hang in SurrogateLockerThread::manipulatePLL
- Closed
-
JDK-6976060 G1: humongous object allocations should initiate marking cycles when necessary
- Closed
(1 relates to)