RFR: Process remaining SATB buffers in final mark/traverse loop instead of separate phase
Aleksey Shipilev
shade at redhat.com
Tue Jun 19 17:58:05 UTC 2018
On 06/19/2018 07:53 PM, Roman Kennke wrote:
>> Now, we at the mercy of that racy check to drain the completed buffers. I would not vouch the whole
>> thing works correctly then. It seems that leaving that line alone provides us with guarantees for
>> final-mark. Not sure if the same applies to Traversal.
>>
>> So, I think we can drop DRAIN_SATB template parameter and simplify marking loops then, but not
>> really remove the unconditional SATB draining that guarantees finishing SATBs.
>
> Note that during final-* no mutators are racing with us. Which means
> that num-completed-buffers only ever decrements. Can we see 0 there when
> there are remaining buffers left?
Yes, because there is still a race with other GC threads that modify num-completed-buffers. Do not
expect races only increment/decrement in the "natural way". There is no natural way. You can
introduce racy-predicated code if there is guaranteed non-racy recovery. SCM::drain_satb_buffers()
is that recovery, let's not give up on that, especially since there seem to be no performance win in
avoiding it.
-Aleksey
More information about the shenandoah-dev
mailing list