RFR (S): CR 6902115: G1:assert(ignore_max_completed||thread->is_Java_thread()||SafepointSynchronize::is_at_safepoint())
John.Cuthbertson at Sun.COM
Tue Dec 8 00:32:22 PST 2009
Can I have a couple of volunteers to review the new set of changes for
this CR - they are located at
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
More information about the hotspot-gc-dev