RFR (S) 8078438: Interpreter should support conditional card marks (UseCondCardMark)
mikael.gerdin at oracle.com
Tue Apr 28 13:28:30 UTC 2015
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:
# 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.
More information about the hotspot-gc-dev