Collection set is empty -> conc mark cancelled

[Roman Kennke]

Am Donnerstag, den 24.11.2016, 14:40 +0100 schrieb Aleksey Shipilev:
> 
> On 11/24/2016 02:31 PM, Aleksey Shipilev wrote:
> > Hi,
> > 
> > On 11/24/2016 02:17 PM, Roman Kennke wrote:
> > > Interestingly, I ran into this myself when I played with
> > > heuristics
> > > yesterday :-)
> > > 
> > > > My question is: what's the purpose for that _collection_set-
> > > > >count()
> > > > ==
> > > > 0 check?
> > > 
> > > dunno. The idea might have been that if the cset ends up empty,
> > > something is wrong. But as you say, it seems superfluous.
> > > 
> > > >  Seems superfluous to me, because we had already had our mark,
> > > > and heading to conc evac. What are we canceling? Seems
> > > > incorrect to
> > > > assume that empty collection set is somehow the detractor from
> > > > the  conc
> > > > mark -- like in the benchmark above, where rootset mutates, but
> > > > no
> > > > garbage is effectively produced.
> > > > 
> > > > Or, at very least, should we reset the concgc flag somewhere
> > > > else?
> > 
> > It is being reset after full GC. All other uses of cancel_concgc()
> > trigger the full GC, except this one. So, there are two options:
> > 
> >  a) Drop the cset-is-empty check, and probably spin back to
> > concurrent
> > mark again on the next cycle;
> > 
> > -    if (_collection_set->count() == 0)
> > -      cancel_concgc();
> > -
> > 
> > 
> >  b) Cancel the mark, but also schedule the full GC:
> > 
> > -    if (_collection_set->count() == 0)
> > +    if (_collection_set->count() == 0) {
> > +      concurrent_thread()->schedule_full_gc();
> >        cancel_concgc();
> > +    }
> > 
> > 
> > Both options resolve the hiccup. The question is, do we need to
> > treat
> > empty cset specially or not? Since this is a corner case, we may
> > want to
> > play it safe with option (b). Thoughts?
> 
> OTOH, it is bad to punish the garbage-free application with full GCs
> here. Even heuristics would not save us here: "aggressive" would
> trigger
> mark, discover no garbage, and do the full GC nevertheless.

If there is no garbage, I'd say carry on, skip evacuation (or let it
run with empty, which should be fast).

Would be nice if heuristics detects that no garbage is created (e.g. by
observing no allocations or writes), and avoid GC, but that is a
different topic.

ROman