RFR (S): Avoid evacuation if concurrent GC was cancelled

[Roman Kennke]

Am Montag, den 05.12.2016, 12:25 -0500 schrieb Zhengyu Gu:
> 114 // b. Cancel evacuation, if in progress
> 115 if (_heap->is_evacuation_in_progress()) {
> 116 MutexLocker mu(Threads_lock);
> 117 _heap->set_evacuation_in_progress(false);
> 118 }
> 
> 
> I think that we can eliminate Threads_lock above by changing the
> assertion below:
> 
> void JavaThread::set_evacuation_in_progress_all_threads(bool in_prog)
> {
>    assert(Threads_lock->owned_by_self(), "must hold
> Threads_lock");       <==== assert_locked_or_safepoint(Threads_lock)
>    _evacuation_in_progress_global = in_prog;
>    for (JavaThread* t = Threads::first(); t != NULL; t = t->next()) {
>      t->set_evacuation_in_progress(in_prog);
>    }
> }

No, I don't think so. We're iterating over the threads, so we should
hold that lock. However, as I mentioned in that other email, the
VMThread should already hold it. Now that I think about it again, it's
probably not going to deadlock, it's simply re-entrant. In any case,
acquiring it should not be necessary.

Roman

> 
> 
> Thanks,
> 
> -Zhengyu
> 
> On 12/05/2016 11:00 AM, Aleksey Shipilev wrote:
> > Hi,
> > 
> > Currently, when concurrent GC is canceled, we still enter the VM
> > operation for
> > concurrent evacuation, only to exit it quickly and slide into the
> > full GC. This
> > causes *two* back-to-back safepoints: one short from evac, and
> > another large for
> > full GC. While short one is normally short, it can hit the unlucky
> > scheduling
> > outlier and drag the pause time up.
> > 
> > This change avoids going to evac if conc GC was canceled:
> >    http://cr.openjdk.java.net/~shade/shenandoah/cancel-no-evac/webr
> > ev.01/
> > 
> > Additionally, it resets the mark bitmaps before full GC with
> > parallel workers,
> > not concurrent ones, which would be important once Zhengyu trims
> > down the number
> > of concurrent workers.
> > 
> > Testing: hotspot_gc_shenandoah, jcstress (tests-all/quick)
> > 
> > Thanks,
> > -Aleksey
> >