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

[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);
   }
}


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/webrev.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
>