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