RFR(S): 8039042: G1: Phantom zeros in cardtable

Per Liden per.liden at oracle.com
Tue May 20 08:14:15 UTC 2014


Thanks Thomas!

/Per

On 05/20/2014 09:06 AM, Thomas Schatzl wrote:
> Hi,
>
> On Tue, 2014-05-20 at 08:19 +0200, Per Liden wrote:
>> Thanks for reviewing Mikael, and thanks for the co-debugging this.
>> Indeed an interesting bug :)
>>
>> Still looking for a capital R review on this patch.
>>
>> Thanks!
>> /Per
>>
>> On 05/13/2014 02:41 PM, Mikael Gerdin wrote:
>>> Per,
>>>
>>> On Tuesday 13 May 2014 12.34.25 Per Liden wrote:
>>>> Summary: We use memset to initialize the cardtable. On Sparc T4 (and
>>>> later) memset uses some special instructions with the side-effect that
>>>> the memory can temporarily be filled with zeros before the actual value
>>>> is set. These phantom zeros can be observed by concurrent readers of
>>>> this memory, which can trick the G1 post-barrier to incorrectly dirty a
>>>> card in a young region. Please see the bug for a more details.
>>>>
>>>> A similar memset-problem has been observed and fixed before
>>>> (JDK-6948537) when using memset on the BlockOffsetTable. Similar to the
>>>> BlockOffsetTable, I'm using the UseMemSetInBOT flag as an indicator of
>>>> whether it's safe to use memset or not. UseMemSetInBOT is not a perfect
>>>> name for this flag as code other than the BOT might want to use it. It's
>>>> also questionable of this should be a command-line flag at all. I've
>>>> filed a separate RFE, JDK-8042930, to do a bit of clean up related to
>>>> this flag.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039042
>>>> Webrev: http://cr.openjdk.java.net/~pliden/8039042/webrev.0/
>
>    looks good.
>
> Thomas
>
>




More information about the hotspot-gc-dev mailing list