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

Mikael Gerdin mikael.gerdin at oracle.com
Tue Apr 28 11:13:13 UTC 2015


Kim, Aleksey,

On 2015-04-28 00:19, 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've thought about the interaction of UseCondCardMark with CMS a bit 
when I did 8014555 but in the end I didn't thoroughly investigate the 
interactions there, partially because I don't know of any regular 
testing of UseCondCardMark.

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

I agree that it shouldn't be a problem for non-concurrent collectors.

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

I had a quick look at the precleaning code in CMS, and it appears to 
write CardTableModRefBS::precleaned_val (0x1) to each card table byte it 
processes concurrently.
The UseCondCardMark enabled write barrier only checks for 0x0,(clean 
cards have the value 0xff) so it seems like precleaned cards will be 
overwritten with 0x0 by the write barrier.

/Mikael

>
> Thanks,
> -Aleksey.
>
>


More information about the hotspot-runtime-dev mailing list