RFR: Process remaining SATB buffers in final mark/traverse loop instead of separate phase
Roman Kennke
rkennke at redhat.com
Tue Jun 19 19:04:12 UTC 2018
Am 19.06.2018 um 19:58 schrieb Aleksey Shipilev:
> 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.
>
Ok, I restored the two SATB draining phases.
Incremental:
http://cr.openjdk.java.net/~rkennke/satb-final-phase/webrev.01.diff/
Full:
http://cr.openjdk.java.net/~rkennke/satb-final-phase/webrev.01/
Better now?
Roman
More information about the shenandoah-dev
mailing list