Details
-
Bug
-
Resolution: Fixed
-
P3
-
11, 12
-
b01
Description
We run into crashes in JDK 11 with +UseStringDeduplication. The root cause is that StringDedupTable::unlink_or_oops_do() tries to load from an adjusted pointer during G1 Full GC adjust task, i.e. load *p after calling cl->keep_alive(p). The value of p has been updated to a new location, but the new location does not contain a valid object because the object at old p has not been copied yet.
This bug no longer exists in JDK 13 thanks toJDK-8213229, which made this change to g1FullGCAdjustTask.cpp:
```
--- _adjust_string_dedup(NULL, &_adjust, G1StringDedup::is_enabled()) {
+++ _string_dedup_cleaning_task(NULL, &_adjust, false) {
```
This avoids resizing and rehashing StringDedupTable during full GC.
We can fix the bug in JDK 11 with a two-line change, without backportingJDK-8213229.
Attached is a stack trace when this crash happens:
# SIGSEGV (0xb) at pc=0x00007fc9936b48e5 (sent by kill), pid=6664, tid=6696
...
# Problematic frame:
# V [libjvm.so+0x6b48e5] AltHashing::halfsiphash_32(unsigned long, unsigned char const*, int)+0x35
#
...
Current thread (0x000057e67d9e4000): GCTaskThread "GC Thread#1" [stack: 0x00007fc95b2fe000,0x00007fc95b400000] [id=6696]
Stack: [0x00007fc95b2fe000,0x00007fc95b400000], sp=0x00007fc95b3fe268, free space=1024k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x6b48e5] AltHashing::halfsiphash_32(unsigned long, unsigned char const*, int)+0x35
V [libjvm.so+0x116fd87] StringDedupTable::unlink_or_oops_do(StringDedupUnlinkOrOopsDoClosure*, unsigned long, unsigned long, unsigned int)+0x117
V [libjvm.so+0x116fbb4] StringDedupTable::unlink_or_oops_do(StringDedupUnlinkOrOopsDoClosure*, unsigned int)+0x94
V [libjvm.so+0xa5776c] G1FullGCAdjustTask::work(unsigned int)+0x24c
V [libjvm.so+0x12fe33a] GangWorker::loop()+0x6a
V [libjvm.so+0x12fe1ae] AbstractGangWorker::run()+0x1e
V [libjvm.so+0x1233b8b] Thread::call_run()+0xcb
V [libjvm.so+0x10604d8] thread_native_entry(Thread*)+0x348
C [libpthread.so.0+0x74e8] start_thread+0xc8
This bug no longer exists in JDK 13 thanks to
```
--- _adjust_string_dedup(NULL, &_adjust, G1StringDedup::is_enabled()) {
+++ _string_dedup_cleaning_task(NULL, &_adjust, false) {
```
This avoids resizing and rehashing StringDedupTable during full GC.
We can fix the bug in JDK 11 with a two-line change, without backporting
Attached is a stack trace when this crash happens:
# SIGSEGV (0xb) at pc=0x00007fc9936b48e5 (sent by kill), pid=6664, tid=6696
...
# Problematic frame:
# V [libjvm.so+0x6b48e5] AltHashing::halfsiphash_32(unsigned long, unsigned char const*, int)+0x35
#
...
Current thread (0x000057e67d9e4000): GCTaskThread "GC Thread#1" [stack: 0x00007fc95b2fe000,0x00007fc95b400000] [id=6696]
Stack: [0x00007fc95b2fe000,0x00007fc95b400000], sp=0x00007fc95b3fe268, free space=1024k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x6b48e5] AltHashing::halfsiphash_32(unsigned long, unsigned char const*, int)+0x35
V [libjvm.so+0x116fd87] StringDedupTable::unlink_or_oops_do(StringDedupUnlinkOrOopsDoClosure*, unsigned long, unsigned long, unsigned int)+0x117
V [libjvm.so+0x116fbb4] StringDedupTable::unlink_or_oops_do(StringDedupUnlinkOrOopsDoClosure*, unsigned int)+0x94
V [libjvm.so+0xa5776c] G1FullGCAdjustTask::work(unsigned int)+0x24c
V [libjvm.so+0x12fe33a] GangWorker::loop()+0x6a
V [libjvm.so+0x12fe1ae] AbstractGangWorker::run()+0x1e
V [libjvm.so+0x1233b8b] Thread::call_run()+0xcb
V [libjvm.so+0x10604d8] thread_native_entry(Thread*)+0x348
C [libpthread.so.0+0x74e8] start_thread+0xc8
Attachments
Issue Links
- relates to
-
JDK-8213229 Investigate treating StringTable as weak in young collections
-
- Resolved
-