RFR: Traveral GC heuristics

Aleksey Shipilev shade at redhat.com
Wed Jan 24 11:14:47 UTC 2018


On 01/24/2018 12:12 PM, Roman Kennke wrote:
> Am 24.01.2018 um 11:11 schrieb Aleksey Shipilev:
>> On 01/23/2018 09:41 PM, Roman Kennke wrote:
>>> Differential patch:
>>> http://cr.openjdk.java.net/~rkennke/traversal/webrev.05.diff/
>>> Full patch, including your changes:
>>> http://cr.openjdk.java.net/~rkennke/traversal/webrev.05/
>>
>> Okay! This looks safe enough to push.
>>
>> I have a minor question about why this is needed:
>>
>> 1657     case _degenerated_outside_cycle:
>> 1658       if (shenandoahPolicy()->can_do_traversal_gc()) {
>> 1659         // Not possible to degenerate from here, upgrade to Full GC right away.
>> 1660         cancel_concgc(GCCause::_allocation_failure);
>> 1661         op_degenerated_fail();
>> 1662         return;
>> 1663       }
>>
>> Aren't we good with the usual Degenerated GC cycle here?
>>
> 
> The problem is that degen_outside_cycles goes into normal marking, and something's not up for that.
> I'm hitting asserts when I go there.

That probably indicates a bug? Traversal GC is ought to leave the heap in the state that is ready
for the usual concurrent cycle, no?

> To be honest, I am also not happy to have all this heuristics-specific code/branches all over the
> place. Could this stuff be abstracted into heuristics API? I.e. driver thread calls into heuristics
> to do stuff (e.g. normal-degen, degen-outside-cycle, but also other stuff that is currently
> sprinkled over different places), and heuristics calls the right thing to take care of it?

Baby steps...

-Aleksey



More information about the shenandoah-dev mailing list