RFR: 8079315: UseCondCardMark broken in conjunction with CMS precleaning

[Aleksey Shipilev]

On 05.05.2015 19:20, Andrew Haley wrote:
> On 05/05/2015 04:36 PM, Vitaly Davidovich wrote:
>>>
>>> But I'm at a loss to understand how that helps with the problem of
>>> reading an old value for the card mark.  There still has to be some
>>> sort of happens-before relationship between something and the read of
>>> the card mark.  What good would a store-store do here?
>>
>> My understanding was that the card can be in 1 of 3 states: clean,
>> dirty, precleaned.  Right now if mutator's read of the card floats
>> above the store and it sees "dirty" (e.g. it read "precleaned"), it
>> will not mark the card as dirty and the write is lost.  I think
>> Mikael's idea was that by changing the mutator to check for "!=
>> clean", it will automatically cover either "dirty" or "precleaned",
>> and the 3rd state ("clean") can't happen since CMS preclean thread
>> does not set it to such.  So although you're right in the general
>> sense of there needing to be a happens-before relationship, I think
>> this is a targeted suggestion given the protocol involved.  Or, of
>> course, I misunderstood Mikael's rationale/suggestion.
> 
> Well, yeah, alright.  I'd be happy to submit a patch which does that
> if I had any idea that it was correct.  Mikael's language about a
> "partial solution" worries me.

I think it is misnomer to talk about happens-before at this level.

Just checking: are we assuming that collector recovers from mutator
blindly flipping the card to "dirty", even though collector's
precleaning updates the card to "precleaned"? That seems to be the case,
since otherwise everything is broken even without UseCondCardMark.

Mikael suggestion seems correct to fix the issue at hand: we need to
maintain the order of (store, cardmark-dirty) as detected by collector
-- this requires StoreStore. Plus, mutator should care about
"precleaned" state, thus changing the tested predicate to "!clean".

But I am suspicious about the whole interaction between mutator and
collector. Cautiously speaking, every time I see a conditional update in
a concurrent code, I expect some form of atomic CAS that provides a
global order w.r.t. the particular memory location.

What exactly happens when collector transits card to "clean"? How does
the mutator sees the proper "clean" value for the card mark? Can it miss
the card mark update with UseCondCardMark because it saw the "outdated"
card mark value?

Thanks,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150505/8863599f/signature.asc>