RFR(XS): 8001384: G1: assert(!is_null(v)) failed: narrow oop value can never be zero
Jon Masamitsu
jon.masamitsu at oracle.com
Sat Feb 2 00:00:21 UTC 2013
Fix looks good.
Thanks for the detailed explanation.
On 1/30/2013 11:19 AM, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple volunteers review the changes for this CR - the
> webrev can be found at:
> http://cr.openjdk.java.net/~johnc/8001384/webrev.0/
>
> Background:
> The ReduceInitialCardMarks optimization allows the JIT compiler, in
> some circumstances, to skip generation of the card marks associated
> with the initializing stores of a newly allocated object. The skipped
> card marks are then elided into a single deferred operation.
>
> The deferred card marks are recorded in a field in the allocating
> thread. Typically deferred card marks are flushed (and the associated
> cards dirtied) when another set of card marks is to be deferred for
> the same thread, or at the start of the next GC (in
> CollectedHeap::ensure_parseability()).
>
> The problem here was that the deferred card marks, if any, for a given
> thread were not being flushed when that thread exited. As a result we
> would end up with missing (card marks) write barriers, (in the case of
> G1) missing RSet entries, and dangling references.
>
> The fix is, obviously, flush any deferred cards marks before the
> thread exits, and before flushing the G1 dirty card queue for the thread.
>
> Although the problem was found by G1's marking verification
> (VerifyDuringGC) occasionally detecting missing RSet entries and
> dangling references, I believe this issue affects all the collectors.
>
> Testing:
> runThese bigapp on the failing machine with IHOP=10 and marking
> verification;
> runThese on my local workstation with IHOP=5 and marking verification;
> gc test suite to sanity test the other collectors.
>
> Thanks,
>
> JohnC
>
>
>
>
More information about the hotspot-gc-dev
mailing list