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

[Mikael Gerdin]

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.

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

I think the concept of relaxed memory ordering  archs and CMS is still 
fairly new territory for most people on hotspot-gc-dev, we've been 
living safely in TSO land for a while.

SAP has been supporting ppc64 and ia64 ports for a long time, they 
probably have some idea here.

/Mikael

>
> Andrew.
>