Claus Ibsen created CAMEL-23872:
-----------------------------------
Summary: camel-tui - Add JFR Old Object Sample panel for memory
leak diagnosis
Key: CAMEL-23872
URL: https://issues.apache.org/jira/browse/CAMEL-23872
Project: Camel
Issue Type: New Feature
Reporter: Claus Ibsen
The TUI heap histogram panel (GC.class_histogram) shows instance counts and
shallow sizes per class, but cannot answer "why is this object still alive" —
it lacks reference chains back to GC roots.
JFR has a built-in jdk.OldObjectSample event that tracks objects surviving
multiple GC cycles and includes a reference chain back to the GC root. This is
the lightest-weight way to diagnose memory leaks without parsing a full .hprof
heap dump.
h3. Proposed workflow in TUI
# User sees heap growing in the existing heap histogram panel
# User triggers a JFR recording with jdk.OldObjectSample enabled
# After some time, stops the recording
# TUI shows old object samples: class name, allocation stack trace, and the
reference chain back to GC root
# User can identify what is holding objects alive (e.g. "10,000 Exchange
objects held by ArrayList in MyAggregationStrategy.cache")
h3. Benefits
* Non-invasive: sampling-based, no full GC trigger, no large .hprof file
* Zero overhead when not recording (JVM JIT short-circuits)
* Built into the JDK since Java 11, no extra dependencies
* Answers the key memory leak question: who keeps the object alive
h3. Implementation needs
* Dev console command to start/stop JFR recording with OldObjectSample enabled
* CLI command to trigger and display results
* TUI panel to visualize old object samples with reference chains
* MCP tool for AI agent access
This complements the existing heap histogram panel: histogram answers "what is
using memory", JFR answers "why is it not being collected".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
