G1ConcurrentStringDeduplication lacks unit

[marschall]

G1ConcurrentStringDeduplication doesn't have any comments so it's a bit hard to make sense of. It currently has

• startingStringVolume: double
• endingStringVolume: double
• reduction: double
• percentReduction: double

All these are double and not long without any comments. It is unclear if the values are in bytes, in which case long would be more appropriate see MemoryPoolSummary, or in a unit, if so what the unit is.

For percentReduction it is unclear whether 100 % is represented as 100.0d or 1.0d.

[brunoborges]

/relevance-check

[github-actions]

Relevance Assessment: Still Relevant

• Summary: The G1ConcurrentStringDeduplication class still has all four double fields (startingStringVolume, endingStringVolume, reduction, percentReduction) with no JavaDoc explaining units or value ranges. The issue's concerns remain entirely unaddressed.

• Evidence:

  • The class G1ConcurrentStringDeduplication.java is unchanged — no documentation has been added to any fields or getters.
  • The parser in PreUnifiedG1GCParser.java (lines 832–838) reveals that startingStringVolume, endingStringVolume, and reduction are populated via trace.toKBytes(), meaning the values are in kilobytes — but this is not documented anywhere on the event class.
  • percentReduction is populated via trace.getDoubleGroup(10), and from the example log line (avg 96.2%), it appears 100% is represented as 100.0 — again, not documented.
  • No PRs have been submitted to address this issue (searched for G1ConcurrentStringDeduplication in PRs — 0 results).
  • The related issue G1ConcurrentStringDeduplication not working for unified logs #104 (string dedup not working for unified logs) is also still open, suggesting this area of the codebase has received limited attention.
  • The contrast with MemoryPoolSummary (which uses long for byte values) highlighted in the original issue is still valid — the API is inconsistent.

• Recommendation: ✅ Keep open — the issue is still valid and actionable. The fields lack unit documentation, the use of double vs long is still inconsistent with MemoryPoolSummary, and no work has been done to address it. This is a straightforward improvement to API clarity.

Generated by Relevance Check Agent for issue #103