RFR (S) 8078438: Interpreter should support conditional card marks (UseCondCardMark)

[Thomas Schatzl]

Hi,

On Tue, 2015-04-28 at 01:19 +0300, Aleksey Shipilev wrote:
> Hi Kim,
> 
> On 28.04.2015 01:05, Kim Barrett wrote:
> > The G1 post-barrier always checks the old card value before storing
> > the dirty value, without conditionalization on UseCondCardMark.  The
> > x86 G1 post-barrier also precedes the load of the old card value with a
> > StoreLoad membar, which is not present in the proposed change.
> > 
> > That barrier was added by the fix for:
> > 8014555: G1: Memory ordering problem with Conc refinement and card marking
> > 
> > I suspect that issue doesn't apply to non-concurrent collectors.  I
> > don't know whether it would matter for non-G1 concurrent collectors like
> > CMS though.
> 
> I would expect it does not matter for non-concurrent collectors, since
> card table updates should be seen by collector after the mutator stops,
> like all other regular updates in the heap.

Yes.

> It would be interesting to see if CMS really requires the barrier,
> because if so, C1 and C2 UseCondCardMark code is already broken for CMS.
> I would think that if cards can be moved from "dirty" to "clean" state
> when mutator runs concurrently, then you would need a memory barrier in
> mutator's write barrier code, otherwise you can lose the card update...

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.
It seems to be a separate issue, and does not have impact on the
conditional card marking change.

CMS does not clean the card table concurrently to the best of my
knowledge, so there is no risk of loosing an update.

Change looks good to me.

Thanks,
  Thomas