RFR: 8079315: UseCondCardMark broken in conjunction with CMS precleaning

[Vitaly Davidovich]

Hi Mikael,

The duplicate store of dirty would only happen if cache coherence hasn't
caught up yet, which is of course timing dependent but the window is fairly
small on x86 (which is what this CR targets) IME.  It's also not
necessarily the case that the involved cacheline will falsely share with
any other thread.  So, this seems like a benign data race.  Also, isn't
this already the case with the current code? A mutator may not observe
another mutator already marking the card dirty and will smash a "duplicate"
in there.

Having said that, you guys are in better position to make the call.  If
nothing else, I think this change should be highlighted in whichever
release(s) it appears in as people should be on the lookout for possible
perf regressions associated with this.

sent from my phone
On May 6, 2015 9:52 AM, "Mikael Gerdin" <mikael.gerdin at oracle.com> wrote:

> Hi Vitaly,
>
> On 2015-05-06 14:41, Vitaly Davidovich wrote:
>
>> Mikael's suggestion was to make mutator check for !clean and then mark
>> dirty.  If it sees stale dirty, it will write dirty again no?  Today's
>> code
>> would have this problem because it's checking for !dirty, but I thought
>> the
>> suggested change would prevent that.
>>
>
> Unfortunately I don't think my suggestion would solve anything.
>
> If the conditional card mark would write dirty again if it sees a stale
> dirty it's not really solving the false sharing problem.
>
> The problem is not the value that the precleaner writes to the card entry,
> it's that the mutator may see the old "dirty" value which was overwritten
> as part of precleaning but not necessarily visible to the mutator thread.
>
> /Mikael
>
>
>
>> sent from my phone
>> On May 6, 2015 4:53 AM, "Andrew Haley" <aph at redhat.com> wrote:
>>
>>  On 05/05/15 20:51, Vitaly Davidovich wrote:
>>>
>>>> If mutator doesn't see "clean" due to staleness, won't it just mark it
>>>> dirty "unnecessarily" using Mikael's suggestion?
>>>>
>>>
>>> No.  The mutator may see a stale "dirty" and not write anything.  At
>>> least
>>> I haven't seen anything which certainly will prevent that from happening.
>>>
>>> Andrew.
>>>
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150506/dce9695a/attachment.htm>