RFR(S): 7200261: G1: Liveness counting inconsistencies during marking verification

[Jon Masamitsu]

I'm used to seeing a range like [start, end).  That the second index is 
named
last_idx helps but if I were just looking at the call site, I would have 
guessed
wrongly - i.e., thinking it was [start, end).

Jon

On 9/21/2012 9:16 PM, Jesper Wilhelmsson wrote:
> John,
>
> Looks good!
>
> Would it make sense to change set_card_bitmap_range to be exclusive, or even to take a start and a size of the area? I think inclusive functions like this one are unintuitive, especially when the only use of last_idx is used with a +1. Maybe that's a different change?
> /Jesper
>
>
>
> 22 sep 2012 kl. 01:37 skrev John Cuthbertson<john.cuthbertson at oracle.com>:
>
>> Hi Everyone,
>>
>> Can I have a couple of volunteers look over the fix for this CR? The webrev can be found at: http://cr.openjdk.java.net/~johnc/7200261/webrev.0/
>>
>> Summary:
>> The clipping in the code that sets the bits for a range of cards in the "expected" card bitmap that we check the liveness accounting data against was incorrect. This could lead to spurious verification failures. In addition to fixing the clipping, I've upleveled this routine and moved it into ConcurrentMark and now use it to generate the real liveness data.
>>
>> Testing:
>> The failing test cases with marking verification; jprt.
>>
>> Thanks,
>>
>> JohnC