RFR (S): CR 6902115: G1:assert(ignore_max_completed||thread->is_Java_thread()||SafepointSynchronize::is_at_safepoint())

John Cuthbertson John.Cuthbertson at Sun.COM
Wed Dec 9 23:31:14 PST 2009

Hi Everyone,

Based upon review feedback I have modified the code changes so that 
filler objects in TLABs are only zapped/mangled when the TLAB is being 
retired. The new changes can be found at 
http://cr.openjdk.java.net/~johnc/6902115/webrev.3/. As a result of this 
modification, the scope of the changes is reduced as I am no longer 
changing the definitions of a couple of virtual functions.

Testing: the original 6902115 test case, jprt, refworkload.



John Cuthbertson wrote:
> Hi Everyone,
> Can I have a couple of volunteers to review the new set of changes for 
> this CR - they are located at 
> http://cr.openjdk.java.net/~johnc/6902115/webrev.2/.
> Issue:
> A subsequent round of testing with the previously posted change for 
> this CR discovered another similar issue to the 0xbaadbabe being seen 
> while object or block table walking during concurrent refinement. This 
> time active TLABs had been filled with 0xdeafbabe during a remark 
> pause. These TLABs were not retired and subsequent allocation 
> requests, after the pause, overwrote the header for the object 
> representing the mangled space. The object walk (looking for 
> unparsable objects) or the BOT walk during concurrent refinement could 
> see this deafbabe pattern and treat the corresponding space as a 
> parsable object. A possible fix is to skip the mangling/zapping the 
> filler space during G1 concurrent marking.
> Note: The change described above in addition to skipping the mangling 
> of the object header in the TLAB allocation code allowed me to revert 
> the block_start_careful call in the previous webrev back to the 
> original code. I believe the comment in the original version of  
> HeapRegion::oops_on_card_seq_iterate_careful to be valid and the BOT 
> should be filled in, if possible, while walking the objects in a TLAB.
> Testing: refworkload (cms, parallel, G1), the original test case, jprt 
> (still running).
> Thanks,
> JohnC

More information about the hotspot-gc-dev mailing list