RFR: JDK-8226757: Shenandoah: Make Traversal a separate mode

[Roman Kennke]

Hi Aleksey,

>>  Currently, Traversal GC is activated by selecting the 'traversal'
>> heuristic. However, Traversal GC is not exactly a heuristic. It is a
>> whole different mode, that is structurally different from the normal
>> Shenandoah GC operation. In addition to that, it would be useful to have
>> several Traveral GC heuristics, aggressive for testing, compact for low
>> memory footprint, passive to drive Traversal without barriers, etc. The
>> current traversal heuristic would become the Traversal mode's 'adaptive'
>> heuristic.
>>
>> I propose to add a new option -XX:ShenandoahGCMode=normal|traversal that
>> selects the mode of operation, and then Traversal GC can also pick up
>> different heuristics via the usual -XX:ShenandoahGCHeuristics option.
>>
>> The change drops Traversal-specific parts from ShenandoahHeuristics, and
>> re-wires them in more useful ways. A big part of the change is adjusting
>> tests for changed options.
>>
>> http://cr.openjdk.java.net/~rkennke/JDK-8226757/webrev.00/
> 
> Brief look:
> 
> *) I wonder if it makes sense to rework it more thoroughly:
>  modes:      {passive, normal, traversal}
>  heuristics: {aggressive, compact, adaptive, static}
> 
>  ...so that modes select barriers, and heuristics only selects when to start the cycle.

I agree.

So let's say we make a similar class hierarchy like we have for
heuristics, but higher-level, called ShenandoahGCMode. This would:
- Select barriers
- It could also actually drive the GC by moving the various
service_XXX_cycle() as virtual methods in ShenandoahGCMode. Not sure how
degen and fullgc fit into this though.

Heuristics would then only:
- Figure out when to start GC
- Figure out the cset

> *) should_start_normal_gc() is now simply should_start_gc()?

Right.

> *) I guess this can be done in "default_cause", near "default_mode":
> 
>  156         cause = mode == concurrent_traversal ? GCCause::_shenandoah_traversal_gc :
> GCCause::_shenandoah_concurrent_gc;

Yup.

> *) Looks to me, there would be no message printed if we supply wrong mode?

Ah yes, good point. Will fix it.

> *) I don't think it is fair to call it scavenge.

Ah I meant to change it.
I think it is kind of scavenging: it starts at roots, and then scavenges
out objects that it encounters while traversing the heap. Difference to
classical scavenge is that it does not copy objects that are not in
cset. So let's call it 'single-pass' and the normal mode mark-evac-update?

> *) TestWrongBarrierDisable.java: indenting, L58:
> 
>   54         shouldFailAll("-XX:ShenandoahGCHeuristics=adaptive",   concurrent);
>   55         shouldFailAll("-XX:ShenandoahGCHeuristics=static",     concurrent);
>   56         shouldFailAll("-XX:ShenandoahGCHeuristics=compact",    concurrent);
>   57         shouldFailAll("-XX:ShenandoahGCHeuristics=aggressive", concurrent);
>   58         shouldFailAll("-XX:ShenandoahGCMode=traversal",  traversal);
>   59         shouldPassAll("-XX:ShenandoahGCHeuristics=passive",    concurrent);
>   60         shouldPassAll("-XX:ShenandoahGCHeuristics=passive",    traversal);

Good catch. Will fix it.

Let me figure out a useful abstraction for the ShenandoahGCMode and then
I'll post a new webrev.

Thanks for reviewing!
Roman