-
Bug
-
Resolution: Fixed
-
P3
-
17, 19, 20
-
b17
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8334127 | 17.0.13-oracle | Mimoun Ghordou | P3 | Resolved | Fixed | b01 |
JDK-8334704 | 17.0.13 | Paul Hohensee | P3 | Resolved | Fixed | b01 |
I am seeing this failure frequently on linux-x86:
```
$ CONF=linux-x86-server-fastdebug make test TEST=runtime/Thread/ThreadCountLimit.java
...
stdout:
[1.852s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 320k, guardsize: 0k, detached.
[1.852s][warning][os,thread] Failed to start the native thread for java.lang.Thread "Thread-8246"
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 8388608 bytes for Failed to reserve memory for metaspace
# An error report file with more information is saved as:
# /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_runtime_Thread_ThreadCountLimit_java/scratch/0/hs_err_pid2107279.log
[2.019s][warning][os ] Loading hsdis library failed
```
It usually crashes when it tries to do heavy stuff in `OutOfMemoryError` block, which ends up either allocating the metadata for string concat method handles (the most frequent case), or allocating memory for resulting Strings. Sometimes even the threads themselves end up receiving a secondary OOM after main loop catches it.
I think we can strengthen this test significantly, by avoiding unnecessary things in dangerous loops.
Additionally, since the test can foobar the VM and/or experience heap memory runaway, it needs to run with othervm and fixed heap size.
AfterJDK-8255450, this test still runs in tier2.
```
$ CONF=linux-x86-server-fastdebug make test TEST=runtime/Thread/ThreadCountLimit.java
...
stdout:
[1.852s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 320k, guardsize: 0k, detached.
[1.852s][warning][os,thread] Failed to start the native thread for java.lang.Thread "Thread-8246"
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 8388608 bytes for Failed to reserve memory for metaspace
# An error report file with more information is saved as:
# /home/shade/trunks/jdk/build/linux-x86-server-fastdebug/test-support/jtreg_test_hotspot_jtreg_runtime_Thread_ThreadCountLimit_java/scratch/0/hs_err_pid2107279.log
[2.019s][warning][os ] Loading hsdis library failed
```
It usually crashes when it tries to do heavy stuff in `OutOfMemoryError` block, which ends up either allocating the metadata for string concat method handles (the most frequent case), or allocating memory for resulting Strings. Sometimes even the threads themselves end up receiving a secondary OOM after main loop catches it.
I think we can strengthen this test significantly, by avoiding unnecessary things in dangerous loops.
Additionally, since the test can foobar the VM and/or experience heap memory runaway, it needs to run with othervm and fixed heap size.
After
- backported by
-
JDK-8334127 Make runtime/Thread/ThreadCountLimit.java more robust
- Resolved
-
JDK-8334704 Make runtime/Thread/ThreadCountLimit.java more robust
- Resolved
- relates to
-
JDK-8255450 runtime/ThreadCountLimit.java causes high system load
- Resolved
-
JDK-8323964 runtime/Thread/ThreadCountLimit.java fails intermittently on AIX
- Resolved
- links to
-
Commit openjdk/jdk17u-dev/33dbf71b
-
Commit openjdk/jdk/36b61c5d
-
Review openjdk/jdk17u-dev/2614
-
Review openjdk/jdk/10290
(3 links to)