RFR(S): 7194633: G1: Assertion and guarantee failures in block offset table
bengt.rutisson at oracle.com
Wed Nov 21 00:26:00 PST 2012
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
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:
>> 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.
>> GCBasher with -UseMemsetInBOT on sparc
>> Forcibly triggering the failures to check that the error messages made
>> 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.
More information about the hotspot-dev