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

[John Cuthbertson]

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