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

Bengt Rutisson bengt.rutisson at oracle.com
Mon Sep 24 06:44:34 UTC 2012

Hi John,

The actual bug fix looks good. Nice catch! I'll let you battle out the 
inclusion/exclusion boundary values with Jesper and Jon.

I like that you moved set_card_bitmap_range() to ConcurrentMark. One 
question about the <= 8 optimization. I think it would be nice if 
set_card_bitmap_range() didn't have to worry about that. To me it seems 
more like the responsibility of the Bitmap. Maybe we can move that 
optimization in to par_at_put_range() / set_range() ? That way all users 
of these method will get the benefit of the optimization.

Actually there already seem to exist a concept inside Bitmap to handle 
different range sizes. I didn't look very closely, but the RangeSizeHint 
concept seem to address the same issue, right? Can we consolidate this 


On 2012-09-22 01:37, John Cuthbertson wrote:
> 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