RFR: Degenerating concurrent marking

[Zhengyu Gu]

Okay.

-Zhengyu


On 12/17/2016 10:52 AM, Roman Kennke wrote:
> Am Samstag, den 17.12.2016, 14:41 +0100 schrieb Roman Kennke:
>> As suggested by Zhengyu on IRC, I now changed it to:
>>
>>      if (terminator != NULL && terminator->should_force_termination())
>> {
>>        return true;
>>      }
>>
>> makes the code more readable.
> Hmm, no, this didn't work. We need the spinning as was proposed before:
>
> http://cr.openjdk.java.net/~rkennke/degen-marking/webrev.04
>
> This passes all tests that I throw at it.
>
> ok to push?
>
> Roman
>
>> The assert that I observed was not caused by this change and is
>> already
>> fixed.
>>
>> Ok to go now?
>>
>> http://cr.openjdk.java.net/~rkennke/degen-marking/webrev.03
>>
>> Roman
>>
>>
>> Am Freitag, den 16.12.2016, 12:02 -0500 schrieb Zhengyu Gu:
>>> Hi Roman,
>>>
>>> - taskqueue
>>>    
>>>     Adding force termination to TerminatorTerminator seems more
>>> logical to me
>>>
>>> class TerminatorTerminator: public CHeapObj<mtInternal> {
>>> public:
>>>     virtual bool should_exit_termination() = 0;
>>>     virtual bool should_force_termination() = 0;
>>> };
>>>
>>> - shenandoahConcurrentMark.cpp #392
>>>
>>>     Please update assert message.
>>>
>>>
>>> Otherwise, look good to me.
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>> On 12/16/2016 09:55 AM, Roman Kennke wrote:
>>>> This patch implements what I call 'degenerating concurrent
>>>> marking'.
>>>> If, during concurrent mark, we run out of memory, instead of
>>>> stopping,
>>>> throwing away all marking data and doing a full-gc, it gracefully
>>>> hands
>>>> over all existing marking work to the subsequent final-mark
>>>> pause,
>>>> finishes marking there, and kicks of normal marking. The idea
>>>> being
>>>> that in most cases, the OOM is not happening because we got into
>>>> a
>>>> bad
>>>> situation (fragmented heap or such) but only temporary alloc
>>>> bursts
>>>> or
>>>> such, *and* chances are high that we're almost done marking
>>>> anyway.
>>>>
>>>> I made it such that existing mark bitmaps, task queues, SATB
>>>> buffers
>>>> and weakref-queues are left intact, if the heuristics decide to
>>>> go
>>>> into
>>>> degenerated concurrent marking, then the final-mark pause carries
>>>> on
>>>> where concurrent marking left. Interestingly, the code for this
>>>> is
>>>> mostly in place already ... in final marking we already finish
>>>> off
>>>> marking in the way that we need.
>>>>
>>>> I needed to tweak the termination protocol in the taskqueue for
>>>> that,
>>>> and not clear task queues on cancellation. Instead I added a
>>>> 'shortcut'
>>>> in the case we need to terminate without draining the task
>>>> queues.
>>>> Please look at this carefully, I am not totally sure I got that
>>>> right.
>>>>
>>>> In addition, I also re-wrote adaptive heuristics. It will start
>>>> out
>>>> with 10% free threshold (i.e. we start marking when 10% available
>>>> space
>>>> is left), and lower that if we have 5 successful markings in a
>>>> row,
>>>> and
>>>> bump that up if we fail to complete concurrent marking. We limit
>>>> the
>>>> free threshold 30<free_threshold<3. All parameters can be
>>>> configured.
>>>>
>>>> This adaptive heuristics work very well for me, and I'm tempted
>>>> to
>>>> make
>>>> this default soon. It makes much better use of headroom, which
>>>> means
>>>> fewer GC cycles, and thus better throughput.
>>>>
>>>>
>>>> http://cr.openjdk.java.net/~rkennke/degen-marking/webrev.00/
>>>>
>>>> Ok? Opinions?
>>>>
>>>> Roman
>>>>
>>>