RFR: 8079315: UseCondCardMark broken in conjunction with CMS precleaning

[Vitaly Davidovich]

If mutator doesn't see "clean" due to staleness, won't it just mark it
dirty "unnecessarily" using Mikael's suggestion? Current code, however, is
less clear.  Is the load of the card in the mutator an acquiring load or at
least C++ volatile?

sent from my phone
On May 5, 2015 12:53 PM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com>
wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150505/b915368c/attachment.htm>