RFR: 8079315: UseCondCardMark broken in conjunction with CMS precleaning

Vitaly Davidovich vitalyd at gmail.com
Tue May 5 15:36:50 UTC 2015


>
> 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.

As for performance, I don't know the impact, hence "possibly defeat" in my
email.  Intuitively, putting a store-load after every ref write (well, ones
not elided) doesn't sound cheap, even if it's a core-local operation.


On Tue, May 5, 2015 at 11:18 AM, Andrew Haley <aph at redhat.com> wrote:

> Hi,
>
> On 05/05/2015 04:02 PM, Vitaly Davidovich wrote:
>
> > I realize this is a correctness fix, but isn't this going to possibly
> > defeat any perf gain from using conditional card marking in the first
> place
> > (for CMS)?
>
> It shouldn't do.  The idea of the UseCondCardMark AIUI is to reduce
> thrashing of card table cache lines across cores.  StoreLoad, while
> possibly slow, should still be a local operation.  So it all depends
> on what we're trying to optimize: it's still the right thing to use
> on a many-core machine, perhaps not for something smaller.
>
> > Didn't someone suggest a different approach that allows
> > store-store to be used still?
>
> Mikael wrote:
>
> > For UseCondCardMark to be correct with CMS with precleaning it would
> > require a StoreLoad between the field write and the card table load.
> >
> > Another approach to solve this partially would be to change the
> > condition for the conditional card mark from an equality test aginst 0x0
> > (dirty_card_val)
> > to a negated equality test of 0xff (clean_card_val)
> >
> > In that case we would slightly reduce the number of false-sharing
> > inducing card writes and still survive the precleaning phase since
> > precleaning sets the card to 0x1 (precleaned_card_val).
>
> 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?
>
> Andrew.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20150505/fd383f76/attachment.html>


More information about the hotspot-gc-dev mailing list