RFR: Degenerated GC mode for Traversal

Roman Kennke rkennke at redhat.com
Tue Mar 27 11:18:19 UTC 2018


Am 27.03.2018 um 11:53 schrieb Aleksey Shipilev:
> On 03/21/2018 02:04 PM, Roman Kennke wrote:
>> http://cr.openjdk.java.net/~rkennke/traversal-degen/webrev.01/
> 
> Looks okay.
> 
> Questions:
> 
>  *) Commented out line L1669?

It's not needed. Probably an earlier attempt at avoiding evac during degen.

> Why do you need to clear cancellation at L1672?

I think I don't.



> 1669       // set_evacuation_in_progress_at_safepoint(false);
> 1670       op_final_traversal();
> 1671       op_cleanup_bitmaps();
> 1672       clear_cancelled_concgc();
> 1673       return;

I removed both lines.

>  *) In service_concurrent_traversal_cycle, why do we need this check? I thought that coming out with
> cancellation from final_traversal means we have the failure during degen, and it should upgrade to
> Full GC right away?
> 
>  275   if (heap->is_concurrent_traversal_in_progress()) {
>  276     if (check_cancellation_or_degen(ShenandoahHeap::_degenerated_traversal)) return;
>  277   }

We must not break out of the cycle between successful final-traversal
and cleanup phases. This might happen because we're back into Java land
by then, and allocations may fail before we managed to clean up. If this
happens, we would get into degen with trashed regions. Do you have any
suggestions how else to deal with that?

Roman



More information about the shenandoah-dev mailing list