GCtoolkit doesnt find the full gc pattern

[logesh-encipherhealth]

gctoolkit cant identify the full GC present in the log file. The full GC class is there but nothing full GC object was created.

[karianna]

@logesh056 Can you add the log file in question to this ticket

[kcpeppe]

Hi @logesh056,

The parsing makes use of regex. Regex expressions are built up in interfaces that are specific to each collector. For example, the patterns to parse CMS log lines are in CMSPatterns. Here is an example

GCParseRule PARALLEL_REMARK_CLASS_UNLOADING = new GCParseRule("PARALLEL_REMARK_CLASS_UNLOADING", GC_PREFIX + YOUNG_GEN_BLOCK + RESCAN_BLOCK + WEAK_REF_BLOCK + CLASS_UNLOADING_BLOCK + SYMBOL_TABLE_SCRUB_BLOCK + STRING_TABLE_SCRUB_BLOCK + REMARK_BLOCK);

GCParseRule is a utility class of sorts. It knows how to convert the strings into useful data types. The argument in the constructor is the pattern. If you look at YOUNG_GEN+BLOCK, that is a regex fragment that picks out the YOUNG generation block in a log entry. You may find that several GCParseRule objects will make use of that regex fragment. In this case YOUNG_GEN_BLOCK is defined in CMSPatterns.

String YOUNG_GEN_BLOCK = "\[YG occupancy: " + COUNTER + " K \(" + COUNTER + " K\)\]";

COUNTER is defined in a token class. Here are some definitions. As you can see, DECIMAL_POINT has been internationalized.

String DECIMAL_POINT = "(?:\\.|,)";
String INTEGER = "\\d+";
String COUNTER = "(" + INTEGER + ")";

To add a parse rule, you just need to define it in the appropriate parser patterns interface. These regex segments are useful in helping build a matching rule that can be used to extract information from the log entry.

The second thing to do is add a test for the parse rule. We want to make sure that the rule captures the intended log line and no others. You can add the test to appropriate test class in the package com.microsoft.gctoolkit.parser.patterns in the testing directories.

Next, add the rule to the parser. To do this, name the rule and then add it to the ParserRule defined at the top of the parser class. You'll need to define a lamda that will wrap a matching method that will process the information into an JVMEvent. In this it will be a FullGC event. The information will be parsed into a forward reference and once the CPU information is seen, then the forward reference will be converted into a FullGC event which will be published. All of the conversion and publishing should happen automagically.

The final test that may need to be adjusted is the test for the parsers. There are two sets of tests. One that will ensure that the event object contains the correct information and another that will parse the entire test log. You can find examples of these tests in com.microsoft.gctoolkit.parser.patterns and com.microsoft.gctoolkit.parser.unittests.

Note that since the project is modularized we've had to make some decisions w.r.t. package naming to accommodate the rules regarding split packages.

Finally the test log. If you have a test log it needs to be added to the GCToolKit-testdata repository.

HTH

[brunoborges]

/relevance-check

[github-actions]

Relevance Assessment: Likely Outdated

• Summary: This issue lacks the critical information needed to reproduce or act on it, and the codebase has seen significant Full GC parsing improvements since it was filed nearly 3 years ago.

• Evidence:

  • The original reporter was asked to provide the GC log file (comment from @karianna, Jul 2023) but never provided it. Without a sample log, the specific parsing gap cannot be identified or reproduced.
  • The issue body is vague: "gctoolkit cant identify the full GC present in the log file" — no GC collector type, JVM version, log format, or log snippet was shared.
  • The codebase currently has comprehensive Full GC pattern coverage across all major collectors:
    • ParallelPatterns.java — PSFULL, PS_FULL_REFERENCE, PS_FULL_GC_PERM, PS_FULL_GC_META, etc.
    • G1GCPatterns.java — FULL_GC, G1_FULL_DETAILS_REFERENCE_GC, G1_FULL_INTERRUPTS_CONCURRENT_*, etc.
    • UnifiedGenerationalPatterns.java — FULL_GC, FULL_GC_SUMMARY, FULL_GC_PHASE_*
    • ICMSPatterns.java — iCMS_FULL, FULL_GC_ICMS
  • Since this issue was filed, multiple parser fixes have been merged that improve Full GC handling:
    • PR Fix #457 - create missing pauseEvent and publish when appropriate. #461 / commit fadbf1f (Nov 2025) — Fixed missing pauseEvent initialization for Full GC in UnifiedGenerationalParser (issue UnifiedGenerationalParser does not create ForwardReference for Parallel file #457)
    • PR Added missing memory pools for heap regions (old, humongous) and metaspace (class space) in unified G1GC logs. #460 / commit 423dedf (Nov 2025) — Added missing memory pools for heap regions in unified G1GC logs
    • PR Optimize decorator parsing #458 / commit 50464ae (Nov 2025) — Optimized decorator parsing
  • The related issue I find gctoolkit can't parse a CMF my gc log #193 (CMS concurrent mode failure parsing) is more specific and actionable, covering a similar class of problems with an actual log line.
  • The original reporter (logesh Ramesh (@logesh-encipherhealth)) has not engaged with the issue since filing it in July 2023.

• Recommendation: 🗄️ Consider closing — This issue is not actionable without a sample GC log file, which was requested but never provided. The codebase has had significant Full GC parsing improvements since this was filed. If a specific Full GC parsing gap is discovered in the future, a new issue with the actual log file and details would be far more actionable. Issue I find gctoolkit can't parse a CMF my gc log #193 already covers a related, more specific scenario.

Generated by Relevance Check Agent for issue #302