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