- 
    Type:
Bug
 - 
    Resolution: Fixed
 - 
    Priority:
  P1                     
     - 
    Affects Version/s: 11, 12
 - 
    Component/s: hotspot
 
| 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
 
 -