RFR(S): 7194633: G1: Assertion and guarantee failures in block offset table

[Bengt Rutisson]

Looks good to me too.

I like that you introduced the check_index() and check_offset() methods.

One style question. You are using the format macros without white 
spaces. After grepping a bit in the hotspot source I think it is more 
common to have white spaces when using these. So instead of 
"..."SIZE_FORMAT"..", "..."UINT32_FORMAT"..." etc I think it would be 
more hotspot-like to use "..." SIZE_FORMAT "..." and "..." UINT32_FORMAT 
"...".

Bengt


On 2012-11-21 02:40, Srinivas Ramakrishna wrote:
> Looks good to me.
>
> -- ramki
>
> On Tue, Nov 20, 2012 at 4:57 PM, John Cuthbertson <
> john.cuthbertson at oracle.com> wrote:
>
>> Hi Everyone,
>>
>> Can I have a couple of volunteers review the changes at:
>> http://cr.openjdk.java.net/~**johnc/7194633/webrev.0<http://cr.openjdk.java.net/%7Ejohnc/7194633/webrev.0>?
>>
>> Background:
>>
>> While I was testing the fix for 719066 I ran into several assertions and
>> guarantee failures from G1's block offset table when running through jprt.
>> The failures were associated with using a specific version of the sparc
>> memset to initialize the offsets array (see 7192128) which was missing from
>> my 7190666 workspace. The changes in this webrev are the instrumenation and
>> detailed error message changes I made to verify that G1's block offset
>> table was not immune to the memset issue and that the failures from jprt
>> were the same issue. These detailed error messages were invaluable when
>> tracking the issue down.
>>
>> Testing:
>> GCBasher with -UseMemsetInBOT on sparc
>> Forcibly triggering the failures to check that the error messages made
>> sense.
>> jprt
>>
>> It is still my intent to merge G1's BOT with that of the other collectors
>> and remove the large amount of duplicated code (which is a separate CR).
>> When I do that, the detailed error messages will be included in the shared
>> BOT code.
>>
>> Thanks,
>>
>> JohnC
>>