CMS: CPU times are not coming

[AlinaHovakimyan]

CPU times (user, sys, real) DTO(CpuSummary) is null in CMSPauseEvent

[dsgrieve]

@AlinaHovakimyan - can you please submit a log segment for this issue?

[AlinaHovakimyan]

@dsgrieve log file example: cms_gen.log

for each event I am actually receiving 2 ones, one with null cpuSummary, and the second one with it. Please see the screenshots attached:

[kcpeppe]

@AlinaHovakimyan, can you tell me the logging flags you're using?

[brunoborges]

/relevance-check

[github-actions]

Relevance Assessment: Still Relevant

• Summary: The reported bug — CMS pause events being emitted with null CPUSummary — appears to still be present in the codebase. No commits or PRs have addressed this issue since it was filed.

• Evidence:

  • CMSPauseEvent, InitialMark, and CMSRemark classes still exist in api/src/main/java/com/microsoft/gctoolkit/event/generational/.
  • The pre-unified parser (GenerationalHeapParser.java) handles CMS events at lines 825–829 (initialMark) and 1948–1964 (recordRemark), calling extractCPUSummary(line) which returns null if the Times: pattern is not found in the line (GCLogParser.java:259–265).
  • The unified parser (UnifiedGenerationalParser.java) correctly defers CMS event publishing to cpuBreakout() (line 438–472), where CPUSummary is always attached before publishing. However, the reporter's dual-emission issue (one event with null CpuSummary, one with it) suggests the problem may be specific to certain log formats or parser paths.
  • A FLOATING_CPU_BREAKOUT rule (line 280) is mapped to noop, meaning standalone Times: lines are silently discarded — this could contribute to null CpuSummary if the CPU info appears on a separate line from the main event.
  • No commits in the git history reference issue CMS: CPU times are not coming #386. The related fix in commit fadbf1f97 (Fix UnifiedGenerationalParser does not create ForwardReference for Parallel file #457) addressed a different problem (Parallel GC pauseEvent initialization).
  • No PRs have been submitted targeting this CMS CPU summary issue.
  • The reporter provided a sample log file and screenshots showing the dual-emission behavior.

• Recommendation: 💬 Needs maintainer input — The bug appears genuine and reproducible (a sample log and screenshots were provided), and the underlying code has not changed. However, the reporter has not responded to the last question about logging flags (asked Jan 2025, 13+ months ago). A maintainer should decide whether to:

  1. Investigate the sample log independently and fix the root cause, or
  2. Close if CMS support is deprioritized given CMS was removed from the JDK in JDK 14.

Generated by Relevance Check Agent for issue #386