RFR(XS): 8001384: G1: assert(!is_null(v)) failed: narrow oop value can never be zero
john.cuthbertson at oracle.com
Sat Feb 2 01:40:30 UTC 2013
Thanks for looking over the change.
On 2/1/2013 4:00 PM, Jon Masamitsu wrote:
> 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:
>> 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
>> 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
>> 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.
>> runThese bigapp on the failing machine with IHOP=10 and marking
>> runThese on my local workstation with IHOP=5 and marking verification;
>> gc test suite to sanity test the other collectors.
More information about the hotspot-gc-dev