-
Bug
-
Resolution: Fixed
-
P1
-
11, 12
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8210174 | 12 | Tobias Hartmann | P1 | Resolved | Fixed | b09 |
JDK-8210083 | 11.0.2 | Tobias Hartmann | P1 | Resolved | Fixed | b01 |
JDK-8210075 | 11.0.1 | Tobias Hartmann | P1 | Resolved | Fixed | b08 |
Before CompilerThread reaches its destructor, it has to be removed from Threads list, which made it no longer participates safepoints. It opens up a race window that can result safepoint scanning to stumble over the code buffer just deleted by CompilerThread's destructor.
Although, the destructor takes CodeCache_lock, but safepoint walk does not take this lock, so it is a race.
I have seen this problem during Shenandoah tests on a big machine with many cores.
- backported by
-
JDK-8210075 CompilerThread releasing code buffer in destructor is unsafe
- Resolved
-
JDK-8210083 CompilerThread releasing code buffer in destructor is unsafe
- Resolved
-
JDK-8210174 CompilerThread releasing code buffer in destructor is unsafe
- Resolved
- duplicates
-
JDK-8209767 gc/parallel/TestPrintGCDetailsVerbose.java failed with assert in CodeCache::verify_icholder_relocations()
- Closed
- relates to
-
JDK-8205499 C1 temporary code buffers are not removed with -XX:+UseDynamicNumberOfCompilerThreads
- Resolved
-
JDK-8198756 Lazy allocation of compiler threads
- Resolved