RFR(S): 7200261: G1: Liveness counting inconsistencies during marking verification
John Cuthbertson
john.cuthbertson at oracle.com
Mon Sep 24 17:03:11 UTC 2012
Hi Jon,
Thanks for the comments. I'm going to refer you to my reply to Jesper.
If people feel strongly about making the routine exclusive - I'll make
it so.
JohnC
On 09/21/12 22:48, Jon Masamitsu wrote:
> 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
More information about the hotspot-gc-dev
mailing list