RFR: Degenerating concurrent marking

[Roman Kennke]

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