RFR: Degenerated GC mode for Traversal

Aleksey Shipilev shade at redhat.com
Tue Mar 27 11:21:52 UTC 2018


On 03/27/2018 01:18 PM, Roman Kennke wrote:
>>  *) 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?

Ok, that sounds fair. But by this logic, we should not even have the entire block predicated by
is_concurrent_traversal_in_progress, right? Instead, we should go to cleanup unconditionally after
final-traversal. It would be the same thing we do for final-mark -> cleanup pair in normal cycle.

-Aleksey




More information about the shenandoah-dev mailing list