March 2026 - hotspot-jfr-dev

RFR: 8379456: Test jdk/jfr/event/runtime/TestVMInfoEvent.java now fails with java.lang.NoClassDefFoundError: java/lang/management/ManagementFactory
by David Holmes 10 Mar '26

10 Mar '26

The test was implicitly relying on the `java.management` module but we were running it in a test task that specifically used `--limit-modules` to exclude the `java.management` module, hence the test failed with the `NoClassDefFoundError`. The fix is to explicitly add the dependency on the `java.management` module, so that now the test is skipped when run in the --limit-modules test task. Tested in our tier5 testing and locally. Thanks ------------- Commit messages: - 8379456: Test jdk/jfr/event/runtime/TestVMInfoEvent.java now fails with java.lang.NoClassDefFoundError: java/lang/management/ManagementFactory Changes: https://git.openjdk.org/jdk/pull/30173/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30173&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8379456 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/30173.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30173/head:pull/30173 PR: https://git.openjdk.org/jdk/pull/30173

1 0

RFR: 8376106: TestObjectDescription.java intermittent fails Unable to replace class name
by Robert Toyonaga 10 Mar '26

10 Mar '26

This change prevents the counter from overflowing. ### Problem: The counter overflows at 2002 iterations because on each iteration the retry loop calls `testClassLoader.loadClasses(OldObjects.MIN_SIZE / 20)`. `OldObjects.MIN_SIZE` = 99901 , so 99901 / 20 = 4995 classes are loaded each iteration. The constructed `className` must be exactly the same length as "TestClass0000000". Which means the max number of classes loaded can be 9,999,999. After 2002 iterations we hit the limit (2002 * 4995 = 9,999,990). ### Solution Making `classIdCounter` non-`static` forces the counter to reset with each iteration of `TestObjectDescription.asseertObjectDescription`. The maximum value of the counter is now 4995, so it cannot possibly overflow no matter how long it takes to collect the leak samples. Testing: - Re-running the test 60 times never results in overflow. ------------- Commit messages: - spelling - improve test reliability Changes: https://git.openjdk.org/jdk/pull/29945/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29945&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376106 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29945/head:pull/29945 PR: https://git.openjdk.org/jdk/pull/29945

4 27

RFR: 8379412: JfrJavaSupport::new_string should return early if pending exception
by Joel Sikström 10 Mar '26

10 Mar '26

Hello, When running testing in an environment that throws out of memory often, I encountered that `JfrJavaSupport::new_string` does not return early if there's a pending exception. In case of a pending exception, result is likely nullptr, which gets passed to `local_jni_handle`, which in a downstream call checks in an assert that the oop is in the heap via `Universe::heap()->is_in(...)`, which fails. I suggest we should make this more robust by adding a CHECK to `JfrJavaSupport::new_string` so that we don't call into `local_jni_handle` if we have a pending exception. Testing: * open/test/jdk/:jdk_jfr locally on my Mac * Running through Oracle's tier 1-3 ------------- Commit messages: - 8379412: JfrJavaSupport::new_string should return early if pending exception Changes: https://git.openjdk.org/jdk/pull/30118/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30118&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8379412 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/30118.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30118/head:pull/30118 PR: https://git.openjdk.org/jdk/pull/30118

2 4

RFR: 8374490: Test jdk/jfr/event/runtime/TestSafepointEvents.java failed: Expected event 'jdk.SafepointStateSynchronization' to be present
by Markus Grönlund 07 Mar '26

07 Mar '26

Greetings, fixing this test as it is racy in two sections: 1. Initialization: Event enabling happens sequentially: 1. SafepointBegin, 2. SafepointStateSynchronization, 3. SafepointEnd. 2. Teardown: The recording is stopped during a safepoint: This will only include 1 and 2 (but not 3). The test tries to handle 2, but it fails to account for event enabling during initialization. Therefore, the test can end up with three (or more) sets, where only some set "in the middle" is complete. The test fails because it removes the last set, which is correct as it is incomplete, but then expects the first set to be complete, which it might not be because events are enabled serially. Testing: jdk_jfr Markus ------------- Commit messages: - 8374490 Changes: https://git.openjdk.org/jdk/pull/30092/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30092&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374490 Stats: 33 lines in 1 file changed: 6 ins; 17 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/30092.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30092/head:pull/30092 PR: https://git.openjdk.org/jdk/pull/30092

3 5

RFR: 8379230: JFR: Do not store leak context edge idx in markWord
by Markus Grönlund 06 Mar '26

06 Mar '26

Greetings, The LeakProfiler component of JFR uses the lower 32 bits of the markWord of the leak object sample candidates (for event jdk.OldObjectSample) to implement the <sample oop, Edge*> function during the PathsToGcRoots VM_Operation. Technically, the idx used for looking up a side-table (a GrowableArray) is stored into the markWord by shifting up: idx << markWord::lock_bits. Packing more features into the markWord, such as Valhalla’s field layout encodings, and the reduction of markWord bits by Lilliput, has rendered this mapping unmaintainable. The manifest problems are usually hard to debug because of crashes, where it is not apparent what has gone wrong. The result is that new features usually turn off the LeakProfiler component to make progress. Although the function is only used during a safepoint, and only when paths-to-gc-roots=true, with fewer bits free for use in the markWord, even with the original markWord saved to be restored on completion, it is time to move this function out of the markWord. The most straightforward way is to provide yet another HashTable to implement this mapping. There are several ProblemLists excluding JFR OldObjectSample testing in the respective feature branches. I will not update them as part of this change; instead, I will leave it to the branch developers to determine if this fix is sufficient for their respective issues. Testing: jdk_jfr, Thanks Markus ------------- Commit messages: - 8379230 Changes: https://git.openjdk.org/jdk/pull/30062/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30062&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8379230 Stats: 63 lines in 2 files changed: 11 ins; 32 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/30062.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30062/head:pull/30062 PR: https://git.openjdk.org/jdk/pull/30062

2 2

RFR: 8378971: Test jdk/jfr/event/runtime/TestVMInfoEvent.java fails after JDK-8378110 (RuntimeMXBean.getInputArguments())
by Oli Gillespie 04 Mar '26

04 Mar '26

The test relied on the specific formatting of `RuntimeMXBean.getInputArguments`, which has changed - flags from a settings file are now prefixed with `-XX:`. The implementation is still correct, the `VMInfo` event explicitly gives jvmFlags as "JVM Settings File Arguments" so I think it's correct that those remain un-prefixed. Updated to pull the expected 'flags' and 'arguments' separately from the most convenient place I could find, `VMSupport.getAgentProperties`. If this is problematic for any reason, we could soften the check to just make sure we're including the explicit flags/args we know are given, but this would allow the implementation to add spurious arguments. ------------- Commit messages: - Fix test Changes: https://git.openjdk.org/jdk/pull/30003/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30003&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8378971 Stats: 10 lines in 1 file changed: 4 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/30003.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30003/head:pull/30003 PR: https://git.openjdk.org/jdk/pull/30003

4 12