August 2025 - hotspot-jfr-dev

RFR: 8365066: RecordingStream and RemoteRecordingStream do not terminate when the associated Recording is stopped or closed externally
by Chihiro Ito 27 Oct '25

27 Oct '25

Fix an issue where RecordingStream and RemoteRecordingStream do not stop when their underlying the local/remote recording stop. Introduce an internal EventSource abstraction to unify control across local (PlatformRecording) and remote (FlightRecorderMXBean) recordings, ensuring consistent propagation of stop/close and stop time to the consumer streams. Tests updated to validate lifecycle consistency: Verifies that stopping/closing the underlying recording (local and remote) properly stops/closes the corresponding stream. Test: jdk/jdk/jfr ------------- Commit messages: - 8365066: RecordingStream and RemoteRecordingStream do not terminate when the associated Recording is stopped or closed externally Changes: https://git.openjdk.org/jdk/pull/26710/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26710&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365066 Stats: 648 lines in 7 files changed: 584 ins; 30 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/26710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26710/head:pull/26710 PR: https://git.openjdk.org/jdk/pull/26710

4 9

RFR: 8356968: JFR: Compilation event should be enabled for all compilations by default
by Aleksey Shipilev 22 Oct '25

22 Oct '25

In the field, we are using -XX:+PrintCompilation to track compiler performance. Alternatively, -Xlog:jit* prints the same. JFR has a the related jdk.Compilation event that gives us even richer diagnostics. Yet, that event is set at a very high threshold (1000ms), which skips almost all compilations! This threshold is set to such a high value from the beginning. It is fairly normal to have lots of compilations in 100+ ms range individually, and their sum impact is what we are after. Also, the compilations are normally quite rare, and there are a couple of thousands of compiles in most workloads, and they only happen sporadically. This means, the event count without any threshold is not high. Therefore, it would be convenient to make sure that basic Compilation event is enabled unconditionally, e.g. by dropping the default threshold to 0. See more logs in the bug itself. Additional testing: - [x] Ad-hoc tests with printing compilation events - [x] Linux x86_64 server fastdebug, `jdk_jfr` ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/25247/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25247&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356968 Stats: 13 lines in 1 file changed: 0 ins; 12 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25247/head:pull/25247 PR: https://git.openjdk.org/jdk/pull/25247

3 8

RFR: 8362573: Incorrect weight of the first ObjectAllocationSample JFR event (regression)
by Markus Grönlund 30 Sep '25

30 Sep '25

Greetings, Fix to ensure that the ObjectAllocationSample event sample weight property is initialized correctly when the event is enabled. The previous clearing logic has been integrated into the existing thread iteration as part of the notify process, to avoid double passes. In addition, clearing and the event only apply to the set of JavaThreads. This time also includes a regression test. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8362573 Changes: https://git.openjdk.org/jdk/pull/26900/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26900&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8362573 Stats: 194 lines in 7 files changed: 133 ins; 30 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/26900.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26900/head:pull/26900 PR: https://git.openjdk.org/jdk/pull/26900

2 6

RFR: 8366082: Improve queue size computation in CPU-time sampler
by Johannes Bechberger 10 Sep '25

10 Sep '25

Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small. ------------- Commit messages: - Improve queue size computation Changes: https://git.openjdk.org/jdk/pull/26926/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26926&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366082 Stats: 59 lines in 4 files changed: 41 ins; 6 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/26926.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26926/head:pull/26926 PR: https://git.openjdk.org/jdk/pull/26926

5 26

Re: RFR: 8366232: JFR startup messages are shown with -Xlog:jfr+startup=warning
by David Holmes 29 Aug '25

29 Aug '25

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger(a)openjdk.org> wrote: > Only print the JFR startup messages when no or a < warning log level is set explicitly by the user. Functionally yes, but I'm just not sure about the mechanism. Need to think more about it. This reminds me of the flag complexity: FLAG_IS_DEFAULT, FLAG_IS_CMDLINE etc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3235455737

1 0

Re: RFR: 8366232: JFR startup messages are shown with -Xlog:jfr+startup=warning
by Johannes Bechberger 28 Aug '25

28 Aug '25

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger(a)openjdk.org> wrote: > Only print the JFR startup messages when no or a < warning log level is set explicitly by the user. But isn't my PR closer to what the user expects? When you explicitly set the level to `warning`, no `info` level messages should be printed ------------- PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3233467744

1 0

Re: RFR: 8366232: JFR startup messages are shown with -Xlog:jfr+startup=warning
by Johannes Bechberger 28 Aug '25

28 Aug '25

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger(a)openjdk.org> wrote: > Only print the JFR startup messages when no or a < warning log level is set explicitly by the user. The original issue was [JDK-8244190](https://bugs.openjdk.org/browse/JDK-8244190), this PR just fixes a short-coming of the implementation. The limitations is even mentioned in [one of the tests](https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/startupa…: startJfrJvm("-Xlog:jfr+startup=error") .shouldNotContain("[jfr,startup") .shouldNotContain("Started recording") .shouldNotContain("Use jcmd"); // Known limitation. // Can't turn off log with -Xlog:jfr+startup=warning startJfrJvm() .shouldContain("[info][jfr,startup") .shouldContain("Started recording") .shouldContain("Use jcmd"); This PR updates the test too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3232456905

2 1

Re: RFR: 8366232: JFR startup messages are shown with -Xlog:jfr+startup=warning
by David Holmes 28 Aug '25

28 Aug '25

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger(a)openjdk.org> wrote: > Only print the JFR startup messages when no or a < warning log level is set explicitly by the user. What was the original issue? I have forgotten about this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3232364965

1 0

Re: RFR: 8366232: JFR startup messages are shown with -Xlog:jfr+startup=warning
by Johannes Bechberger 28 Aug '25

28 Aug '25

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger(a)openjdk.org> wrote: > Only print the JFR startup messages when no or a < warning log level is set explicitly by the user. The motivation is to better capture the user's intent. When the user doesn't set any warning level, then we keep the default behaviour, for backwards compatibility as in the original change, when the user sets the logging level, then we consider it. You mentioned yourself in the original issue: I'm just not sure we have a way to query if the logging level has been explicitly set to a given value. I just implemented this. I just implemented a way to properly check whether the user didn't specify a logging level, so the code doesn't have to assume that a `warning` logging level means the user didn't set anything. This change tries to reduce confusion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3232196397

1 0

Re: RFR: 8366232: JFR startup messages are shown with -Xlog:jfr+startup=warning
by David Holmes 28 Aug '25

28 Aug '25

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger(a)openjdk.org> wrote: > Only print the JFR startup messages when no or a < warning log level is set explicitly by the user. I can't say I like the general changes to UL to accommodate this. I also don't really like what JFR is already doing. I'm trying to see what the motivation is here. It appears to be "give a verbose startup message but don't label it as a 'warning'". But there is also no guarantee that `jfr+startup` is being logged to `stdout` so this could by-pass the user's control over logging output! ------------- PR Review: https://git.openjdk.org/jdk/pull/26957#pullrequestreview-3163457152

1 0