January 2026 - hotspot-jfr-dev

RFC: Display contextual event fields in jfr view command
by Jaroslav Bachorík 16 Feb '26

16 Feb '26

Hello, 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. Background 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. 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. --- Current State The `jfr print` command already supports displaying contextual events. When printing events, it shows active context fields inline: jfr print recording.jfr jdk.ThreadSleep { Context: Trace.traceId = "abc-123-def" Context: Trace.service = "order-service" startTime = 12:00:01.000 duration = 50 ms ... } This works well for detailed event inspection, but the `jfr view` command (which displays events in a tabular format) has no equivalent capability. --- The Problem 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: 1. Note the timestamp of the event of interest 2. Switch to `jfr print` or manually search for overlapping contextual events 3. Match by thread ID to avoid cross-thread confusion 4. Repeat for every event they want to analyze This breaks the workflow when trying to correlate events with their contexts at scale. --- Proposed Solution Add a `--show-context` flag to `jfr view` that automatically displays contextual event fields as additional columns: jfr view --show-context jdk.ThreadSleep recording.jfr ThreadSleep Time Sleep Time Trace.traceId Trace.service ---------------------------------------------------------------- 12:00:01 50 ms abc-123-def order-service 12:00:02 100 ms abc-123-def order-service 12:00:03 25 ms N/A N/A The context matching rule is: a contextual event is active when contextStart <= eventStart AND contextEnd >= eventStart. Users can optionally filter which context types to display: jfr view --show-context=Span,Trace WorkEvent recording.jfr --- Why This Approach? 1. No runtime overhead - context correlation happens entirely at analysis time 2. No format changes - works with existing recordings that have @Contextual events 3. Backward compatible - recordings remain readable by older tools 4. Flexible - users choose which contexts to display 5. Proven pattern - based on the timeline approach already used in PrettyWriter --- [PoC] Implementation Notes 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. I've also added support for referencing contextual fields in GROUP BY clauses for the `jfr query` command (debug builds), enabling aggregation queries like: SELECT COUNT(*), Trace.traceId FROM WorkEvent GROUP BY Trace.traceId --- Questions for Discussion 1. Is the matching rule (contextStart <= eventStart) correct? An alternative would be to require the event to fall entirely within the context. 2. Should there be a maximum number of context columns to prevent very wide output? 3. Is 1M events a reasonable buffer size? This balances memory (~100MB) with accuracy for long-running contexts. 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? I'd welcome feedback on the approach before proceeding further. Thanks, Jaroslacv

2 4

RFR: 8373096: JFR: Path-to-gc-roots search should be non-recursive
by Thomas Stuefe 16 Feb '26

16 Feb '26

This is a continuation - second attempt - of https://github.com/openjdk/jdk/pull/28659. ---- A customer reported a native stack overflow when producing a JFR recording with path-to-gc-roots=true. This happens regularly, see similar cases in JBS (e.g. https://bugs.openjdk.org/browse/JDK-8371630, https://bugs.openjdk.org/browse/JDK-8282427 etc). We limit the maximum graph search depth (DFSClosure::max_dfs_depth) to prevent stack overflows. That solution is brittle, however, since recursion depth is not a good proxy for thread stack usage: it depends on many factors, e.g., compiler inlining decisions and platform specifics. In this case, the VMThread's stack was too small. This patch rewrites the DFS heap tracer to be non-recursive. This is mostly textbook stuff, but the devil is in the details. Nevertheless, the algorithm should be a straightforward read. ### Memory usage of old vs new algorithm: The new algorithm uses, on average, a bit less memory than the old one. The old algorithm did cost ((avg stackframe size in bytes) * depth). As we have seen, e.g., in JDK-8371630, a depth of 3200 can max out ~1MB of stack space. The new algorithm costs ((avg number of outgoing refs per instanceKlass oop) * depth * 16. For a depth of 3200, we get typical probe stack sizes of 100KB..200KB. But we also cap probestack size, similar to how we cap the max. graph depth. In any case, these numbers are nothing to worry about. For a more in-depth explanation about memory cost, please see the comment in dfsClosure.cpp. ### Possible improvements/simplifications in the future: DFS works perfectly well alone now. It no longer depends on stack size, and its memory usage is typically smaller than BFS. IMHO, it would be perfectly fine to get rid of BFS and rely solely on the non-recursive DFS. The benefit would be a decrease in complexity and fewer tests to run and maintain. It should also be easy to convert into a parallelized version later. I kept the _max_dfs_depth_ parameter for now, but tbh it is no longer very useful. Before, it prevented stack overflows. Now, it is just an indirect way to limit probe stack size. But we also explicitly cap the probe stack size, so _max_dfs_depth_ is redundant. Removing it would require changing the statically allocated reference stack to be dynamically allocated, but that should not be difficult. ### Observable differences There is one observable side effect to the changed algorithm. The non-recursive algorithm processes oops and roots in reverse order. That means we may see different GC roots in JMC now compared to the recursive version of this algorithm. For example, for a static main class member: - One order of root processing may process the CLDG first; this causes the CLDs to be iterated, which iterates the Klass, which iterates the associated j.l.Class object. The reference stack starts at the j.l.Class object, and the root displayed in JMC says "ClassLoader". - Another root processing order may process the global handles first; this causes the AppClassLoader to be processed first, which causes the main class Mirror to be processed, and we also hit the static member, but now the root in JMC is displayed as "Global Object Handle: VM Global" I think that effect is benign - a root is a root. But, as a future improvement, I think displaying the first (or first n) objects of the reference stack would be very helpful to the analyst (possibly more so than just printing the roots). But maybe that feature exists already; I am no JMC expert. ## Testing - I ran extensive tests manually to make sure the resulting jfr files showed the same information (apart from the observable differences mentioned above). - I manually tested that we handle max_depth reached and probestack exhaustion gracefully - I added a new test to execute DFS-only on a very small stack size. Works fine (crashes with stock JVM). - I added a new test that exercises the new array chunking in the tracer - I made sure the patch fixes https://bugs.openjdk.org/browse/JDK-8371630 by running the TestWaste.java with a tiny stack size - crashes without patch, works with patch ------------- Commit messages: - fix after JDK-8375040 - tests - wip - revert unnecessary changes - wip - small stack test - tweaking DFS-BFS test - fix windows build warning - reduce diff - fix performance problem on bfs-dfs mixed mode - ... and 8 more: https://git.openjdk.org/jdk/compare/cba7d88c...5d79624b Changes: https://git.openjdk.org/jdk/pull/29382/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29382&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373096 Stats: 543 lines in 8 files changed: 502 ins; 8 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/29382.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29382/head:pull/29382 PR: https://git.openjdk.org/jdk/pull/29382

3 26

RFR: 8373439: Deadlock between flight recorder & VMDeath
by Bara' Hasheesh 29 Jan '26

29 Jan '26

A simple `PlatformRecorder.isInShutDown` check is added to `PlatformRecording.start` to prevent any new recording from start after the JVM initiates it's shutdown hooks A new test was added that fails without the change & passes with it I also ran `tier1`, `tier2` as well as `jdk_jfr` on Linux x86 ------------- Commit messages: - exception message - Move shutdown check to PlatformRecorder.start & missing space - 8373439: Fix deadlock between recorder start & VMDeath hook Changes: https://git.openjdk.org/jdk/pull/28767/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28767&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373439 Stats: 66 lines in 3 files changed: 64 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28767.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28767/head:pull/28767 PR: https://git.openjdk.org/jdk/pull/28767

5 15

RFR: 8375544: JfrSet::clear should not use memset
by Kim Barrett 21 Jan '26

21 Jan '26

Please review this change to JfrSet::clear to no longer use memset to clear the table data. Instead use value-initialization, similarly to what is done in the set initialization from JDK-8374445. Testing: mach5 tier1-3 ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/29327/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29327&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375544 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29327.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29327/head:pull/29327 PR: https://git.openjdk.org/jdk/pull/29327

2 3

RFR: 8375717: Outdated link in jdk.jfr.internal.JVM javadoc
by Francesco Andreuzzi 21 Jan '26

21 Jan '26

I noticed that several javadoc entries in `jdk.jfr.internal.JVM` are still referencing `createNativeJFR`, which has been removed as part of [JDK-8310661](https://bugs.openjdk.org/browse/JDK-8310661). I propose to replace it with `JVMSupport#createJFR()`. ------------- Commit messages: - replace Changes: https://git.openjdk.org/jdk/pull/29322/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29322&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375717 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29322.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29322/head:pull/29322 PR: https://git.openjdk.org/jdk/pull/29322

2 4

RFR: 8374445: Fix -Wzero-as-null-pointer-constant warnings in JfrSet
by Kim Barrett 16 Jan '26

16 Jan '26

Please review this change to fix JfrSet to avoid triggering -Wzero-as-null-pointer-constant warnings when that warning is enabled. The old code uses an entry value with representation 0 to indicate the entry doesn't have a value. It compares an entry value against literal 0 to check for that. If the key type is a pointer type, this involves an implicit 0 => null pointer constant conversion, so we get a warning when that warning is enabled. Instead we initialize entry values to a value-initialized key, and compare against a value-initialized key. This changes the (currently undocumented) requirements on the key type. The key type is no longer required to be trivially constructible (to permit memset-based initialization), but is now required to be value-initializable. That's currently a wash, since all of the in-use key types are fundamental types (traceid (u8) and Klass*). Testing: mach5 tier1-3 (tier3 is where most jfr tests are run) ------------- Commit messages: - fix -Wzero-as-null-poniter-constant warnings in jfrSet.hpp Changes: https://git.openjdk.org/jdk/pull/29022/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29022&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374445 Stats: 10 lines in 1 file changed: 3 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29022.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29022/head:pull/29022 PR: https://git.openjdk.org/jdk/pull/29022

3 10

RFR: 8373096: JFR leak profiler: path-to-gc-roots search should be non-recursive
by Thomas Stuefe 15 Jan '26

15 Jan '26

A customer reported a crash when producing a JFR recording with `path-to-gc-roots=true`. It was a native stack overflow that occurred during the recursive path-to-gc-root search performed in the context of PathToGcRootsOperation. We try to avoid this by limiting the maximum search depth (DFSClosure::max_dfs_depth). That solution is brittle, however, since recursion depth is not a good proxy for thread stack usage: it depends on many factors, e.g., compiler inlining decisions and platform specifics. In this case, the VMThread's stack was too small. This RFE changes the algorithm to be non-recursive. Note that as a result of this change, the order in which oop maps are walked per oop is reversed : last oops are processed first. That should not matter for the end result, however. The search is still depth-first. Note that after this patch, we could easily remove the max_depth limitation altogether. I left it in however since this was not the scope of this RFE. Testing: - Tested manually with very small (256K) thread stack size for the VMThread - the patched version works where the old version crashes out - Compared JFR recordings from both an unpatched version (with a large enough VMThread stack size) and a patched version; made sure that the content of "Old Object Sample" was identical - Ran locally all jtreg tests in jdk/jfr - GHAs ------------- Commit messages: - remove test output - Copyright - start Changes: https://git.openjdk.org/jdk/pull/28659/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28659&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373096 Stats: 70 lines in 2 files changed: 40 ins; 17 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/28659.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28659/head:pull/28659 PR: https://git.openjdk.org/jdk/pull/28659

5 21

Using JFR both with ZGC degrades application throughput
by Fabrice Bibonne 15 Jan '26

15 Jan '26

Hi all, I would like to report a case where starting jfr for an application running with zgc causes a significant throughput degradation (compared to when JFR is not started). My context : I was writing a little web app to illustrate a case where the use of ZGC gives a better throughput than with G1. I benchmarked with grafana k6 my application running with G1 and my application running with ZGC : the runs with ZGC gave better throughputs. I wanted to go a bit further in explanation so I began again my benchmarks with JFR to be able to illustrate GC gains in JMC. When I ran my web app with ZGC+JFR, I noticed a significant throughput degradation in my benchmark (which was not the case with G1+JFR). Although I did not measure an increase in overhead as such, I still wanted to report this issue because the degradation in throughput with JFR is such that it would not be usable as is on a production service. I wrote a little application (not a web one) to reproduce the problem : the application calls a little conversion service 200 times with random numbers in parallel (to be like a web app in charge and to pressure GC). The conversion service (a method named `convertNumberToWords`) convert the number in a String looking for the String in a Map with the number as th key. In order to instantiate and destroy many objects at each call, the map is built parsing a huge String at each call. Application ends after 200 calls. Here are the step to reproduce : 1. Clone https://framagit.org/FBibonne/poc-java/-/tree/jfr+zgc_impact (be aware to be on branch jfr+zgc_impact) 2. Compile it (you must include numbers200k.zip in resources : it contains a 36 Mo text files whose contents are used to create the huge String variable) 3. in the root of repository : 3a. Run `time java -Xmx4g -XX:+UseZGC -XX:+UseCompressedOops -classpath target/classes poc.java.perf.write.TestPerf #ZGC without JFR` 3b. Run `time java -Xmx4g -XX:+UseZGC -XX:+UseCompressedOops -XX:StartFlightRecording -classpath target/classes poc.java.perf.write.TestPerf #ZGC with JFR` 4. The real time of the second run (with JFR) will be considerably higher than that of the first I ran these tests on my laptop : - Dell Inc. Latitude 5591 - openSUSE Tumbleweed 20260108 - Kernel : 6.18.3-1-default (64-bit) - 12 × Intel(R) Core(tm) i7-8850H CPU @ 2.60GHz - RAM 16 Gio - openjdk version "25.0.1" 2025-10-21 - OpenJDK Runtime Environment (build 25.0.1+8-27) - OpenJDK 64-Bit Server VM (build 25.0.1+8-27, mixed mode, sharing) - many tabs opened in firefox ! I also ran it in a container (eclipse-temurin:25) on my laptop and with a windows laptop and came to the same conclusions : here are the measurements from the container : | Run with | Real time (s) | |-----------|---------------| | ZGC alone | 7.473 | | ZGC + jfr | 25.075 | | G1 alone | 10.195 | | G1 + jfr | 10.450 | After all these tests I tried to run the app with an other profiler tool in order to understand where is the issue. I join the flamegraph when running jfr+zgc : for the worker threads of the ForkJoinPool of Stream, stack traces of a majority of samples have the same top lines : - PosixSemaphore::wait - ZPageAllocator::alloc_page_stall - ZPageAllocator::alloc_page_inner - ZPageAllocator::alloc_page So many thread seem to spent their time waiting in the method ZPageAllocator::alloc_page_stall when the JFR is on. The JFR periodic tasks threads has also a few samples where it waits at ZPageAllocator::alloc_page_stall. I hope this will help you to find the issue. Thank you very much for reading this email until the end. I hope this is the good place for such a feedback. Let me know if I must report my problem elsewhere. Be free to ask me more questions if you need. Thank you all for this amazing tool !

4 8

RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented
by Markus Grönlund 14 Jan '26

14 Jan '26

Alternative for solving [JDK-8371014](https://bugs.openjdk.org/browse/JDK-8371014) Also includes a fix for [JDK-8373257](https://bugs.openjdk.org/browse/JDK-8373257) ------------- Commit messages: - reordering - update comment - is_recording() conditional - remove tautology - 8371014 Changes: https://git.openjdk.org/jdk/pull/29094/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29094&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371014 Stats: 292 lines in 15 files changed: 219 ins; 18 del; 55 mod Patch: https://git.openjdk.org/jdk/pull/29094.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29094/head:pull/29094 PR: https://git.openjdk.org/jdk/pull/29094

4 10

[jdk26] Integrated: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented
by Markus Grönlund 14 Jan '26

14 Jan '26

On Tue, 13 Jan 2026 18:14:09 GMT, Markus Grönlund <mgronlun(a)openjdk.org> wrote: > 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented This pull request has now been integrated. Changeset: f3bdee89 Author: Markus Grönlund <mgronlun(a)openjdk.org> URL: https://git.openjdk.org/jdk/commit/f3bdee89ed1acd8a61989dd580f11ff184166520 Stats: 292 lines in 15 files changed: 219 ins; 18 del; 55 mod 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented Reviewed-by: ysuenaga Backport-of: f23752a75ee3d3af0853eff9c678d2496bb1cf58 ------------- PR: https://git.openjdk.org/jdk/pull/29203

1 0