-
Bug
-
Resolution: Fixed
-
P4
-
15
-
b18
I was looking att JFR profiles in JMC and noticed that ZGC reported a few pause sub-phases during our concurrent phase. So, we have a top-level concurrent phase, with an sub-phase pause.
It looks like Shenandoah does as well, except they don't have a top-level phase around the unloading phase.
The problem is that the GCTraceTime uses GCTimer::register_gc_phase_start and defaults to reporting a pause.
I'm considering changing this so that register_gc_phase_start doesn't allow the callers to decide what phase type it is, but instead inherit it from the encompassing phase.
This requires the callers to be explicit when about what type is used when a top-level phase is opened. Most places are, a few needs to be changed.
Some side-effects of this:
1) ConcurrentGCTimer::_is_concurrent_phase_active becomes redundant
2) Need to add concurrent sub-phases to JFR (just like we have for pauses)
It looks like Shenandoah does as well, except they don't have a top-level phase around the unloading phase.
The problem is that the GCTraceTime uses GCTimer::register_gc_phase_start and defaults to reporting a pause.
I'm considering changing this so that register_gc_phase_start doesn't allow the callers to decide what phase type it is, but instead inherit it from the encompassing phase.
This requires the callers to be explicit when about what type is used when a top-level phase is opened. Most places are, a few needs to be changed.
Some side-effects of this:
1) ConcurrentGCTimer::_is_concurrent_phase_active becomes redundant
2) Need to add concurrent sub-phases to JFR (just like we have for pauses)