G1 question: concurrent cleaning of dirty cards

[John Cuthbertson]

Hi Igor,

On 6/28/2013 9:47 AM, Igor Veresov wrote:
>
> On Jun 28, 2013, at 7:08 AM, "Doerr, Martin" <martin.doerr at sap.com 
> <mailto:martin.doerr at sap.com>> wrote:
>
>> Hi Igor,
>> we didn’t find an easy and feasible way to ensure the ordering, either.
>> Grabbing the buffers and cleaning the cards at safepoints might be 
>> the best solution.
>
> Would anybody from the G1 team like to think about that?

I've been thinking about this issue on an off for the last few weeks 
when I get the time. I mentioned it to Vladimir a couple of times to get 
his input.

>> Maybe removing the barrier that flushes the store to the cardtable 
>> makes the problem more likely to occur.
>> I guess the purpose of the barrier was exactly to avoid this problem
>> (which should be working perfectly if the post barriers had StoreLoad 
>> barriers, too).
>
> Yeah, but like you noted that would have a horrific effect on 
> performance. So, it's probably best to bunch the work up to at least 
> eliminate the need of extra work when, say, you're looping and storing 
> to a limited working set (G1 uses the cardtable basically for that 
> purpose). The safepoint approach will likely require more memory for 
> buffers and the load will be spiky, and if the collection were to 
> happen right after we grabbed the buffers the collector will have to 
> process all of them which is not going to work well for 
> predictability. But nothing better comes to mind at this point.
> Btw, there are already periodic safepoints to do bias locking 
> revocations, so may be it would make sense to piggyback on that.

Piggy backing on all the other safepoint operations might work if they 
happen frequently enough but I don't know if that 's the case. And as 
you, even then there will be times where we haven't had a safepoint for 
a while and will have a ton of buffers to process at the start of the pause.

It might be worth adding a suitable memory barrier to the G1 post write 
barrier and evaluating the throughput hit.

JohnC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130628/02e8910c/attachment.htm>