<div dir="ltr">Hello,<br><br>I'd like to propose adding context display support to the `jfr view` command. This would allow users to see which @Contextual events were active when other events occurred, without requiring any changes to the JFR recording format or runtime.<br><br>Background<br><br>Back in 2021, there was a discussion on this list about adding a Recording Context concept to JFR (thread starting at 2021-June/002777). Erik suggested an alternative to modifying the event format: use dedicated context events with begin/end markers and correlate them during recording analysis.<br><br>This proposal implements exactly that approach on the tooling side. When users have events with @Contextual annotated fields (such as trace IDs, span IDs, or request contexts), they can now view which contexts were active during any event - all computed at analysis time from the existing recording data.<br>---<br><br>Current State<br><br>The `jfr print` command already supports displaying contextual events. When printing events, it shows active context fields inline:<br><br>  jfr print recording.jfr<br><br>  jdk.ThreadSleep {<br>    Context: Trace.traceId = "abc-123-def"<br>    Context: Trace.service = "order-service"<br>    startTime = 12:00:01.000<br>    duration = 50 ms<br>    ...<br>  }<br><br>This works well for detailed event inspection, but the `jfr view` command (which displays events in a tabular format) has no equivalent capability.<br>---<div><br>The Problem<br><br>When using `jfr view` to analyze recordings from distributed systems, users cannot see which contexts were active. The tabular format is often preferred for scanning many events quickly, but without context information users must:<br><br>1. Note the timestamp of the event of interest<br>2. Switch to `jfr print` or manually search for overlapping contextual events<br>3. Match by thread ID to avoid cross-thread confusion<br>4. Repeat for every event they want to analyze<br><br>This breaks the workflow when trying to correlate events with their contexts at scale.<br>---</div><div><br>Proposed Solution<br><br>Add a `--show-context` flag to `jfr view` that automatically displays contextual event fields as additional columns:<br><br> jfr view --show-context jdk.ThreadSleep recording.jfr<br></div><div><br> ThreadSleep<br><br>  Time        Sleep Time   Trace.traceId       Trace.service<br>  ----------------------------------------------------------------<br>  12:00:01    50 ms        abc-123-def         order-service<br>  12:00:02    100 ms      abc-123-def         order-service<br>  12:00:03    25 ms        N/A                       N/A<br><br>The context matching rule is: a contextual event is active when contextStart <= eventStart AND contextEnd >= eventStart.<br><br>Users can optionally filter which context types to display:<br><br>  jfr view --show-context=Span,Trace WorkEvent recording.jfr<br>---</div><div><br>Why This Approach?<br><br>1. No runtime overhead - context correlation happens entirely at analysis time<br>2. No format changes - works with existing recordings that have @Contextual events<br>3. Backward compatible - recordings remain readable by older tools<br>4. Flexible - users choose which contexts to display<br>5. Proven pattern - based on the timeline approach already used in PrettyWriter<br>---</div><div><br>[PoC] Implementation Notes<br><br>The implementation tracks context per-thread using a timeline-based approach similar to PrettyWriter.java. Events are buffered in a priority queue ordered by timestamp. Contextual events contribute both start and end timestamps, and active contexts are tracked per-thread to prevent cross-thread leakage. Memory is bounded (~1M events) to handle large recordings. Queries without --show-context bypass this entirely, so there's no overhead for existing usage.<br><br>I've also added support for referencing contextual fields in GROUP BY clauses for the `jfr query` command (debug builds), enabling aggregation queries like:<br><br>  SELECT COUNT(*), Trace.traceId FROM WorkEvent GROUP BY Trace.traceId<br>---</div><div><br>Questions for Discussion<br><br>1. Is the matching rule (contextStart <= eventStart) correct? An alternative would be to require the event to fall entirely within the context.<br>2. Should there be a maximum number of context columns to prevent very wide output?<br>3. Is 1M events a reasonable buffer size? This balances memory (~100MB) with accuracy for long-running contexts.<br>4. The `jfr print` command already shows context - should there be a way to disable it for consistency, or is the current always-on behavior correct?<br><br><br>I'd welcome feedback on the approach before proceeding further.<br><br>Thanks,</div><div><br>Jaroslacv</div></div>