RFR: Traversal should be reported as concurrent cycle in gc+stats

[Roman Kennke]

Am 20.03.2018 um 18:45 schrieb Aleksey Shipilev:
> Traversal GC would print this in gc+stats:
> 
> [73.539s][info][gc,stats]     0 successful partial concurrent GCs
> [73.539s][info][gc,stats]
> [73.539s][info][gc,stats]     0 successful concurrent GCs
> [73.539s][info][gc,stats]       0 invoked explicitly
> [73.539s][info][gc,stats]
> [73.539s][info][gc,stats]     0 Degenerated GCs
> [73.539s][info][gc,stats]       0 caused by allocation failure
> [73.539s][info][gc,stats]       0 upgraded to Full GC
> [73.539s][info][gc,stats]
> [73.539s][info][gc,stats]     0 Full GCs
> [73.539s][info][gc,stats]       0 invoked explicitly
> [73.539s][info][gc,stats]       0 caused by allocation failure
> [73.539s][info][gc,stats]       0 upgraded from Degenerated GC
> [73.539s][info][gc,stats]
> 
> We miss the report that traversal had finished successfully:
> 
> diff -r eef8fad72696 src/hotspot/share/gc/shenandoah/shenandoahConcurrentThread.cpp
> --- a/src/hotspot/share/gc/shenandoah/shenandoahConcurrentThread.cpp	Tue Mar 20 16:25:36 2018 +0100
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahConcurrentThread.cpp	Tue Mar 20 18:43:43 2018 +0100
> @@ -271,6 +271,8 @@
>    if (check_cancellation_or_degen(ShenandoahHeap::_degenerated_traversal)) return;
> 
>    heap->entry_cleanup_bitmaps();
> +
> +  heap->shenandoahPolicy()->record_success_concurrent();
>  }
> 
>  void ShenandoahConcurrentThread::service_concurrent_normal_cycle(GCCause::Cause cause) {
> 
> Thanks,
> -Aleksey
> 
> 

Funny that we found the same thing from two different angles: I added it
(locally) to support adaptive traversal heuristics :-)

Go for it!

Roman