RFR: Traveral GC heuristics

[Roman Kennke]

Am 24.01.2018 um 12:14 schrieb Aleksey Shipilev:
> 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?

In the middle of traversal GC? I don't know... Also, cannot, in any 
case, expect *concurrent* cycle to work: we don't have the barriers for 
that. Theoretically, we could do STW normal cycle, but what would be the 
point? I'd rather have a STW degen traversal pickup.

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

;-)