Request for review: 8044406: JVM crash with JDK8 (build 1.8.0-b132) with G1 GC

Poonam Bajaj poonam.bajaj at
Sun Aug 17 00:54:46 UTC 2014


Could I have reviews for the fix for a G1 GC crash:

8044406 <>: JVM crash 
with JDK8 (build 1.8.0-b132) with G1 GC

The crash happens with the following stack trace:
Stack: [0x00007fd435a1f000,0x00007fd435b20000],  sp=0x00007fd435b1bc30,  
free space=1011k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
C=native code)
V  []  
HeapWord*, void const*)+0xf1
V  []  DirtyCardToOopClosure::do_MemRegion(MemRegion)+0x64
V  []  ScanRSClosure::doHeapRegion(HeapRegion*)+0x374
V  []  
V  []  G1RemSet::scanRS(OopsInHeapRegionClosure*, 
CodeBlobToOopClosure*, int)+0xdc
V  []  
CodeBlobToOopClosure*, int)+0x145
V  []  G1CollectedHeap::g1_process_strong_roots(bool, 
SharedHeap::ScanningOption, OopClosure*, OopsInHeapRegionClosure*, 
G1KlassScanClosure*, int)+0x224
V  []  G1ParTask::work(unsigned int)+0xb88
V  []  GangWorker::loop()+0xcf
V  []  java_start(Thread*)+0x108

Here, the GC thread crashes while scanning the RemSet (part of the 
non-CSet regions). And it happens to scan a region to which another 
thread in G1ParEvacuateFollowersClosure is copying contents to, and this 
region was found out to be an Old GC alloc region.

This change makes sure that we fill up the last card of the Old GC alloc 
region that was being allocated into, with a dummy object so that it 
does not get scanned by the remset scanning GC threads.

This change applies cleanly to 8u and 7u repos.

Thanks to Thomas Schatzl for his help in investigating the crash and 
suggesting this solution.

- Testing by Coherence QA


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the hotspot-gc-dev mailing list