RFR: Degenerating concurrent marking

[Roman Kennke]

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.

Ok. Like this:

http://cr.openjdk.java.net/~rkennke/degen-marking/webrev.01/

Roman

> 
> 
> 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
> > 
> 
>