-
Bug
-
Resolution: Fixed
-
P3
-
21, 22
-
b15
-
aarch64
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8316495 | 21.0.2 | Aleksey Shipilev | P3 | Resolved | Fixed | b02 |
#
# Internal Error (/home/nicgas01/jdk/src/hotspot/share/code/codeCache.inline.hpp:49), pid=674258, tid=674369
# assert(cb != __null) failed: must be
#
# JRE version: OpenJDK Runtime Environment (21.0) (slowdebug build 21-internal-adhoc.nicgas01.jdk)
# Java VM: OpenJDK 64-Bit Server VM (slowdebug 21-internal-adhoc.nicgas01.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, shenandoah gc, linux-aarch64)
# Problematic frame:
# V [libjvm.so+0x130a680] CodeCache::find_blob_and_oopmap(void*, int&)+0x11c
#
(Full log file attached.)
We've seen this failure intermittently on AArch64 when running the jtreg tests with Shenandoah but it's easy to reproduce if you run the Skynet test directly with a small heap size. E.g.
$ java -Xmx256m -XX:+UseShenandoahGC --enable-preview Skynet 100
This seems to be related to method unloading since if you run with -Xlog:codecache=debug there's a log line like the following corresponding to the PC value which asserts in CodeCache::find_blob_and_oopmap() moments later:
[20.239s][debug][codecache] *flushing nmethod 591/0x0000ffffe1138990. Live blobs:1510/Free CodeCache:117454Kb
If I run it with -XX:-MethodFlushing I don't see the assertion failure.
# Internal Error (/home/nicgas01/jdk/src/hotspot/share/code/codeCache.inline.hpp:49), pid=674258, tid=674369
# assert(cb != __null) failed: must be
#
# JRE version: OpenJDK Runtime Environment (21.0) (slowdebug build 21-internal-adhoc.nicgas01.jdk)
# Java VM: OpenJDK 64-Bit Server VM (slowdebug 21-internal-adhoc.nicgas01.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, shenandoah gc, linux-aarch64)
# Problematic frame:
# V [libjvm.so+0x130a680] CodeCache::find_blob_and_oopmap(void*, int&)+0x11c
#
(Full log file attached.)
We've seen this failure intermittently on AArch64 when running the jtreg tests with Shenandoah but it's easy to reproduce if you run the Skynet test directly with a small heap size. E.g.
$ java -Xmx256m -XX:+UseShenandoahGC --enable-preview Skynet 100
This seems to be related to method unloading since if you run with -Xlog:codecache=debug there's a log line like the following corresponding to the PC value which asserts in CodeCache::find_blob_and_oopmap() moments later:
[20.239s][debug][codecache] *flushing nmethod 591/0x0000ffffe1138990. Live blobs:1510/Free CodeCache:117454Kb
If I run it with -XX:-MethodFlushing I don't see the assertion failure.
- backported by
-
JDK-8316495 Shenandoah: STW mark should keep nmethod/oops referenced from stack chunk alive
- Resolved