RFR (S) 8078438: Interpreter should support conditional card marks (UseCondCardMark)

Andrew Haley aph at redhat.com
Tue Apr 28 15:03:29 UTC 2015


On 04/28/2015 02:28 PM, Mikael Gerdin wrote:
> 
> On 2015-04-28 15:13, Andrew Haley wrote:
>> On 04/28/2015 02:06 PM, Mikael Gerdin wrote:
>>>
>>> On 2015-04-28 14:45, Andrew Haley wrote:
>>>> On 04/28/2015 11:56 AM, Thomas Schatzl wrote:
>>>>> Somewhat related, note that C2 adds a MemBarRelease before the actual
>>>>> card table store (see StoreCMNode) I think to ensure store ordering (the
>>>>> card mark must be visible after the reference write). So the given
>>>>> aarch64 code seems to be missing something already.
>>>>
>>>> I don't think it's missing anything.  It has the barrier in the correct
>>>> place when G1 is in use, and CMS isn't supposed to need one.
>>>
>>> I think it does depend on StoreStore ordering, the field write must be
>>> visible if the dirty card byte is visible.
>>
>> Hmm.  We were told otherwise here before.  Does the code which scans
>> the card table use a load barrier after each read of the card?  If not
>> the StoreStore won't have any effect anyway.
> 
> Consider the following sequence of events:
> Mutator:		CMS-preclean:
> # o.x == NULL
> o.x = a			
> card[o >> 9] = 0x0	finds card[o >> 9] == 0x0
> 			reads o.x, finds NULL
> 			writes card[o >> 9] = 0x1
> #			o.x == a becomes visible
> 
> CMS-remark occurs, o.x is not scanned because card[o >> 9] == 0x1 which 
> is not dirty.

I see.

> There's no load barrier in the card scanning code that I'm aware of.

In which case the store barrier won't have any effect.  I see your
point, but there really is no point fixing only one end of this bug.
If this ordering matters there really has to be a barrier after
reading the card.

Thanks,

Andrew.


More information about the hotspot-gc-dev mailing list