RFR: Process remaining SATB buffers in final mark/traverse loop instead of separate phase

[Roman Kennke]

Am 19.06.2018 um 21:04 schrieb Roman Kennke:
> 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
> 

Oops, forgot hg qrefresh before making webrev. Please review this:

 Incremental:
 http://cr.openjdk.java.net/~rkennke/satb-final-phase/webrev.02.diff/
 Full:
 http://cr.openjdk.java.net/~rkennke/satb-final-phase/webrev.02/