December 2025 - hotspot-jfr-dev

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: 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

RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented
by Yasumasa Suenaga 09 Jan '26

09 Jan '26

The jtreg test TestEmergencyDumpAtOOM.java runs into the following error on ppc64 platforms. JFR emergency dump would be kicked at `VMError::report_and_die()`, then Java thread for JFR would not work due to secondary signal handler for error reporting. Passed all of jdk_jfr tests on Linux AMD64. ------------- Commit messages: - Fix typo - Delete TestEmergencyDumpAtOOM.java from ProblemList - 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented Changes: https://git.openjdk.org/jdk/pull/28563/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28563&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371014 Stats: 31 lines in 8 files changed: 23 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/28563.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28563/head:pull/28563 PR: https://git.openjdk.org/jdk/pull/28563

4 12

RFR: 8367949: JFR: MethodTrace double-counts methods that catch their own exceptions
by Erik Gahlin 08 Jan '26

08 Jan '26

Could I have a review of a PR that changes how the instrumentation of the MethodTrace and MethodTiming events is implemented, so they handle exceptions in a better way? For constructors, the current implementation is still used in certain corner cases. A proper implementation would require data-flow analysis, but for all practical purposes this code should work fine. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Trailing whitespace - Fix trailing whitespaec - Fix whitespaces - Initial Changes: https://git.openjdk.org/jdk/pull/28947/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28947&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367949 Stats: 361 lines in 5 files changed: 331 ins; 1 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/28947.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28947/head:pull/28947 PR: https://git.openjdk.org/jdk/pull/28947

5 12

[jdk26] RFR: 8373122: JFR build failure with CDS disabled due to -Werror=unused-function after JDK-8365400
by Hao Sun 07 Jan '26

07 Jan '26

Hi all, This pull request contains a backport of commit [e1d81c09](https://github.com/openjdk/jdk/commit/e1d81c0946364a266a006481a8f… from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Hao Sun on 23 Dec 2025 and was reviewed by Markus Grönlund, Jie Fu and Francesco Andreuzzi. Thanks! ------------- Commit messages: - Backport e1d81c0946364a266a006481a8fbbac24c7e6c6a Changes: https://git.openjdk.org/jdk/pull/28976/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28976&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373122 Stats: 28 lines in 1 file changed: 14 ins; 14 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28976/head:pull/28976 PR: https://git.openjdk.org/jdk/pull/28976

3 7

[JDK21u] JDK-8337994 REDO backport failure analysis - Missing prerequisite changes from JDK-8316241
by Cetin, Ozan 24 Dec '25

24 Dec '25

Attachment protected by Amazon: [JDK-8316241 Analysis.pdf] https://eu-central-1.secure-attach.amazon.com/c7b94fc4-394c-4db0-82f2-8629a… Amazon has replaced the attachment in this email with a download link. Downloads will be available until January 23, 2026, 09:10 (UTC+00:00). [Tell us what you think] https://amazonexteu.qualtrics.com/jfe/form/SV_ehuz6zGo8YnsRKK [For more information click here] https://docs.secure-attach.amazon.com/guide Hi JFR team, I've been investigating the test failures that caused JDK-8346108 (the revert of JDK-8337994 REDO in JDK21u). This is related to the native memory leak when not recording any JFR events (JDK-8335121). Summary Based on our investigation, we believe the JDK-8337994 (REDO) backport to JDK21 failed because it appears to depend on API changes introduced in the original JDK-8316241 fix that were never backported to JDK21. Our theory is that the REDO fix assumes the existence of infrastructure that only exists in later mainline releases. Root Cause Analysis The Missing Prerequisite The original JDK-8316241 fix (commit b2a39c576706622b624314c89fa6d10d0b422f86) introduced several key changes to jfrTypeSetUtils.hpp/.cpp: 1. API Change: should_do_loader_klass(const Klass* k) → should_do_cld_klass(const Klass* k, bool leakp) 2. New Data Structure: Added _klass_loader_leakp_set for separate tracking of leakp (leak profiler) path klasses 3. New Function: get_cld_klass(CldPtr cld, bool leakp) in jfrTypeSet.cpp that properly enqueues CLD klasses via JfrTraceId::load() What Happens Without These Changes The REDO fix attempts to use get_cld_klass() which calls should_do_cld_klass(klass, leakp), but in the JDK21 backport: * JDK21 still has the old API: should_do_loader_klass(const Klass* k) (no leakp parameter) * JDK21 lacks _klass_loader_leakp_set for separate tracking * The get_cld_klass() function doesn't exist in the JDK21 codebase This causes the assert(IS_SERIALIZED(class_loader_klass)) to fail in write_cld() because the CLD's class_loader_klass is never properly enqueued for serialization during the leakp path. Test Failure Mechanism (TestChunkIntegrity.java) 1. TestClassLoader loads MyClass 2. Event commits with clazz = MyClass 3. JFR rotation writes MyClass to chunk 4. MyClass's CLD references TestClassLoader Klass 5. BUG: TestClassLoader Klass not serialized (leakp path broken) 6. Chunk written with broken reference 7. In slowdebug: assert(IS_SERIALIZED(class_loader_klass)) fails 8. In release: "Events don't match" when comparing chunks The Fix I've been able to get a local jdk21u build passing all tests (including slowdebug) by backporting JDK-8316241 and resolving the resulting conflicts. The key changes are: 1. jfrTypeSetUtils.hpp // OLD (JDK21 current) bool should_do_loader_klass(const Klass* k); // NEW (with leakp support) bool should_do_cld_klass(const Klass* k, bool leakp); 2. jfrTypeSetUtils.cpp // Added _klass_loader_leakp_set member GrowableArray<const Klass*>* _klass_loader_leakp_set; // Updated implementation bool JfrArtifactSet::should_do_cld_klass(const Klass* k, bool leakp) { assert(k != nullptr, "invariant"); assert(_klass_loader_set != nullptr, "invariant"); assert(_klass_loader_leakp_set != nullptr, "invariant"); return not_in_set(leakp ? _klass_loader_leakp_set : _klass_loader_set, k); } 3. jfrTypeSet.cpp - Added get_cld_klass() static inline KlassPtr get_cld_klass(CldPtr cld, bool leakp) { if (cld == nullptr) { return nullptr; } assert(leakp ? IS_LEAKP(cld) : used(cld), "invariant"); KlassPtr cld_klass = cld->class_loader_klass(); if (cld_klass == nullptr) { return nullptr; } if (should_do_cld_klass(cld_klass, leakp)) { if (current_epoch()) { // KEY FIX: Enqueue the klass for serialization JfrTraceId::load(cld_klass); } else { artifact_tag(cld_klass, leakp); } return cld_klass; } return nullptr; } Proposed Action Based on this, it appears that backporting JDK-8337994 (REDO) alone may not be sufficient, and that some or all the prerequisite infrastructure changes from JDK-8316241 may also need to be backported. Additionally, there may be other upstream commits (such as 8323631<https://github.com/openjdk/jdk/commit/e2d6023cb9667dc9911e0af421d6dd0c78f6b…>) in JDK24 that were made on top of JDK-8316241 that could also be required for the fix to not cause other possible errors. We would appreciate guidance on identifying any additional changes that might need to be included in the backport. If this direction makes sense, I'm happy to prepare a proper patch for review. References * JDK-8335121<https://bugs.openjdk.org/browse/JDK-8335121>: Native memory leak when JFR is enabled but no events are emitted * JDK-8316241<https://github.com/openjdk/jdk/commit/b2a39c576706622b624314c89fa6d10d0b422…>: Test jdk/jdk/jfr/jvm/TestChunkIntegrity.java failed (original fix) * JDK-8337994<https://github.com/openjdk/jdk/commit/6a9a867d645b8fe86f4ca2b04a43bf5aa8f9d…>: [REDO] Native memory leak when not recording any events * JDK-8346108<https://bugs.openjdk.org/browse/JDK-8346108>: Revert of REDO in JDK21u due to test failures Best Regards, Ozan

1 0

RFR: 8373122: JFR build failure with CDS disabled due to -Werror=unused-function after JDK-8365400
by Hao Sun 23 Dec '25

23 Dec '25

`get_source(const AOTClassLocation* cl, JavaThread* jt)` is only used by `JfrClassDefineEvent::on_restoration()` within an `INCLUDE_CDS` guard. Add the same `INCLUDE_CDS` guard to mitigate the GCC warning. Tests: JDK build with CDS disabled passed on both x86_64 and aarch64. tier1~3 passed on both x86_64 and aarch64. ------------- Commit messages: - 8373122: JFR build failure with CDS disabled due to -Werror=unused-function after JDK-8365400 Changes: https://git.openjdk.org/jdk/pull/28917/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28917&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373122 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28917.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28917/head:pull/28917 PR: https://git.openjdk.org/jdk/pull/28917

4 9

Withdrawn: 8365306: Provide OS Process Size and Libc statistic metrics to JFR
by duke 19 Dec '25

19 Dec '25

On Wed, 13 Aug 2025 09:42:57 GMT, Thomas Stuefe <stuefe(a)openjdk.org> wrote: > This provides the following new metrics: > - `ProcessSize` event (new, periodic) > - vsize (for analyzing address-space fragmentation issues) > - RSS including subtypes (subtypes are useful for excluding atypical issues, e.g. kernel problems that cause large file buffer bloat) > - peak RSS > - process swap (if we swap we cannot trust the RSS values, plus it indicates bad sizing) > - pte size (to quickly see if we run with a super-large working set but an unsuitably small page size) > - `LibcStatistics` (new, periodic) > - outstanding malloc size (important counterpoint to whatever NMT tries to tell me, which alone is often misleading) > - retained malloc size (super-important for the same reason) > - number of libc trims the hotspot executed (needed to gauge the usefulness of the retain counter, and to see if a customer employs native heap auto trimming (`-XX:TrimNativeHeapInterval`) > - `NativeHeapTrim` (new, event-driven) (for both manual and automatic trims) > - RSS before and RSS after > - RSS recovered by this trim > - whether it was an automatic or manual trim > - duration > - `JavaThreadStatistic` > - os thread counter (new field) (useful to understand the behavior of third-party code in our process if threads are created that bypass the JVM. E.g. some custom launchers do that.) > - nonJava thread counter (new field) (needed to interprete the os thread counter) > > Notes: > - we already have `ResidentSetSize` event, and the new `ProcessSize` event is a superset of that. I don't know how these cases are handled. I'd prefer to throw the old event out, but JMC has a hard-coded chart for RSS, so I kept it in unless someone tells me to remove it. > > - Obviously, the libc events are very platform-specific. Still, I argue that these metrics are highly useful. We want people to use JFR and JMC; people include developers that are dealing with performance problems that require platform-specific knowledge to understand. See my comment in the JBS issue. > > I provided implementations, as far as possible, to Linux, MacOS and Windows. > > Testing: > - ran the new tests manually and as part of GHAs This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/26756

1 0

RFR: 8373490: JFR Leak Profiler: path-to-gc-root very slow for large object arrays
by Thomas Stuefe 14 Dec '25

14 Dec '25

I see a steep performance decrease (as in: path-to-gc-root can hang for minutes or hours) with the JFR Leak Profiler under the following conditions: 1) We have large object arrays on the heap 2) We start with BFS, but at some point, we fallback to DFS. This happens when the BFS edge queue becomes too large (see https://github.com/tstuefe/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf5…) This, in turn, is more likely to happen with large object arrays. Both BFS and DFS are very fast on their own; when one enforces DFS (via the SkipBFS parameter), all is well. If BFS runs without DFS, all is well, too. The problem only occurs when mixing these two. The problem is more likely with large object arrays on small heaps, since the size of the BFS edge queue is tied to 1/20 of the heap size. The problem can be provoked more easily by decreasing the size of the BFS edge queue in the code. In my tests (a modified variant of `TestJcmdDumpPathToGCRoots.java`), with a BFS edge queue size artificially reduced to 4 MB, I could reproduce the problem with an object array of 200k - 300k elements, with the following results: - Object Array size of 200,000 elements: BFS only, all is well (~5 seconds) - Object Array size of 250,000 elements: BFS/DFS mixed, (~200 seconds) - Object Array size of 300,000 elements: BFS/DFS mixed, (~650 seconds) The run time is the square of the array size, see explanation below. With the default edge queue size of 32MB, we only hit that DFS fallback path when processing arrays of >2mio, and for arrays as big as these, the search basically hangs forever. Examining the problem more closely, I see: - BFS search starts iterating over the object array. It will find that its edge queue is too small, and will drop down to DFS for every single object element. That in itself is not the problem. - It will then continue to process edges, and re-process the array oop over and over again: passing its oop down to `DFSClosure::find_leaks_from_edge` for every element inside this array. The effect is that, for an array of size N, we process that array oop N times. So the runtime will be O^2 with respect to the array size. The reason for this is a missing mark check at the border between BFS and DFS. Tests: - I provided a regression test that provokes the pathological behavior before the patch and is very quick to finish with the patch (TestJcmdDumpPathToGCRootsBFSDFS.java#bfsdfs). I also manually verified the resulting JFR file and confirmed that I see the gc roots listed for the array elements. - I ran JFR jtreg tests manually ------------- Commit messages: - fix - start Changes: https://git.openjdk.org/jdk/pull/28781/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28781&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373490 Stats: 208 lines in 2 files changed: 202 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28781.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28781/head:pull/28781 PR: https://git.openjdk.org/jdk/pull/28781

3 9

RFR: 8370715: JFR: Races are possible when dumping recordings
by Robert Toyonaga 04 Dec '25

04 Dec '25

#### Summary This PR changes the JFR snapshot dumping code so that multiple JFR recordings (potentially from different processes) racing to write the same dump destination won't mix their data. #### Problem The dump destination file is created and/or wiped when a recording is started, but not wiped again before actually copying over the chunks during a dump. So in the window of time between creating/wiping and dumping chunks, another recording could write to the same dump destination and have it's chunks added to the snapshot. This can happen with either a single JVM or multiple JVMs that are racing. #### Proposed fix This PR ensures that any data previously written to the dump destination is wiped before the new recording's data is written. File locking is also done while chunks are being written. Testing: - new test `jdk/jdk/jfr/api/recording/dump/TestDumpOverwrite.java` - Tier 1 ------------- Commit messages: - small changes to transferChunks and add test Changes: https://git.openjdk.org/jdk/pull/28460/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28460&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370715 Stats: 87 lines in 2 files changed: 86 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28460.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28460/head:pull/28460 PR: https://git.openjdk.org/jdk/pull/28460

4 11