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

[Srinivas Ramakrishna]

Yes, I agree. Having the white-space around the *_FORMAT macros is the
standard we've generally followed, and it's good to
stick to it. I have noticed (even well in the past) that G1 code has often
elided the white-space, but it would be nice to keep most of the
code-base consistent wrt this style (or at least new code when it touches a
file). May be we could add it to the HotSpot style guide so
that people are aware of it, and such consistency maintained.

-- ramki

On Wed, Nov 21, 2012 at 12:26 AM, Bengt Rutisson
<bengt.rutisson at oracle.com>wrote:

>
> 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/%7E**johnc/7194633/webrev.0>
>>> <http://**cr.openjdk.java.net/%7Ejohnc/**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
>>>
>>>
>