RFR (S): CR 6902115: G1:assert(ignore_max_completed||thread->is_Java_thread()||SafepointSynchronize::is_at_safepoint())
John.Cuthbertson at Sun.COM
Wed Dec 9 23:31:14 PST 2009
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
> 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).
More information about the hotspot-gc-dev