January 2026 - hotspot-jfr-dev

Re: [jdk26] RFR: 8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented
by Yasumasa Suenaga 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 Marked as reviewed by ysuenaga (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29203#pullrequestreview-3659821661

2 1

Re: [jdk26] RFR: 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 Can you please also review the backport to 26 @YaSuenag ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29203#issuecomment-3748504204

1 0

[jdk26] RFR: 8372321: TestBackToBackSensitive fails intermittently after JDK-8365972
by Erik Gahlin 14 Jan '26

14 Jan '26

8372321: TestBackToBackSensitive fails intermittently after JDK-8365972 ------------- Commit messages: - Backport 556bddfd9439d1bad698ab5134317ce263a36b04 Changes: https://git.openjdk.org/jdk/pull/29191/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29191&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372321 Stats: 47 lines in 1 file changed: 21 ins; 14 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/29191.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29191/head:pull/29191 PR: https://git.openjdk.org/jdk/pull/29191

2 2

[jdk26] RFR: 8373106: JFR suspend/resume deadlock on macOS in pthreads library
by Markus Grönlund 13 Jan '26

13 Jan '26

8373106: JFR suspend/resume deadlock on macOS in pthreads library ------------- Commit messages: - Backport b070367bdf980ef1c257cab485927db39b544241 Changes: https://git.openjdk.org/jdk/pull/29207/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29207&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373106 Stats: 62 lines in 1 file changed: 12 ins; 18 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/29207.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29207/head:pull/29207 PR: https://git.openjdk.org/jdk/pull/29207

2 3

RFR: 8373106: JFR suspend/resume deadlock on macOS in pthreads library
by Markus Grönlund 13 Jan '26

13 Jan '26

Greetings, this change effectively reverts [JDK-8358429](https://bugs.openjdk.org/browse/JDK-8358429), which was an attempt to minimize the time the Threads_lock is held during JFR sampling. That change was premised on the, at the time, two known reasons for why we held the Threads_lock during the entire sampling interval. After this change, subtle deadlocks happened on macOS, very intermittently, in the pthreads library, in that a suspended thread could be the owner of an internal process lock, a process lock that was then needed when sending pthread_kill signal to resume it. By rolling back to holding the Threads_lock for the entire duration of the sampling interval (like we have done for many many years in the era before JFR Cooperative Sampling), we prevent JavaThreads from calling os::create_thread(). I have decided to rollback the solution to the version we know work, instead of attempting a more granular solution, perhaps using sigprocmask() to create a critical section around pthread_create in os_bsd.cpp. This is something we might want to do later, but more time is then needed for falsifying / verifying the correct fix. Testing: jdk_jfr, stress testing Thanks Markus PS Indirect barriers removed are explicitly re-inserted as per [JDK-8373485](https://bugs.openjdk.org/browse/JDK-8373485) ------------- Commit messages: - 8373106 Changes: https://git.openjdk.org/jdk/pull/29178/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29178&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373106 Stats: 62 lines in 1 file changed: 12 ins; 18 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/29178.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29178/head:pull/29178 PR: https://git.openjdk.org/jdk/pull/29178

2 5

[jdk26] RFR: 8373485: JFR Crash during sampling: assert(jt->has_last_Java_frame()) failed: invariant
by Markus Grönlund 13 Jan '26

13 Jan '26

8373485: JFR Crash during sampling: assert(jt->has_last_Java_frame()) failed: invariant ------------- Commit messages: - Backport 543a972222118155e4c72c6f2d32d154c5dfd442 Changes: https://git.openjdk.org/jdk/pull/29189/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29189&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373485 Stats: 11 lines in 1 file changed: 7 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29189.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29189/head:pull/29189 PR: https://git.openjdk.org/jdk/pull/29189

3 4

RFR: 8373485: JFR Crash during sampling: assert(jt->has_last_Java_frame()) failed: invariant
by Markus Grönlund 13 Jan '26

13 Jan '26

Greetings, When sampling threads in state _thread_in_native, there is a missing memory barrier when UseSystemMemoryBarrier is used, because it must be emitted manually. Testing: jdk_jfr Thanks Markus PS "threads_lock" local variable was renamed to "lock" not to confuse with the global Threads_lock. ------------- Commit messages: - 8373485 Changes: https://git.openjdk.org/jdk/pull/29155/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29155&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373485 Stats: 11 lines in 1 file changed: 7 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29155/head:pull/29155 PR: https://git.openjdk.org/jdk/pull/29155

3 8

RFR: 8372321: TestBackToBackSensitive fails intermittently after JDK-8365972
by Erik Gahlin 12 Jan '26

12 Jan '26

Could I have a review of a PR that attempts to harden a test? Sometimes, ClassLoaderStatistics events are dropped, probably due to a bug in the RecordingStream class when starting multiple recordings simultaneously. This is not a bug related to back-to-back chunks, so I decided to use an EventFileStream instead. I also use TestClassLoader for verification purposes. Using PlatformClassLoader shouldn't be a problem, but it seems more prudent to have an actual object/class on the heap for the class loader that needs to be checked. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Use EventStream - Remove empty line - Initial Changes: https://git.openjdk.org/jdk/pull/29117/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29117&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372321 Stats: 47 lines in 1 file changed: 21 ins; 14 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/29117.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29117/head:pull/29117 PR: https://git.openjdk.org/jdk/pull/29117

3 4

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