June 2025 - hotspot-jfr-dev

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

JFR: Scrubbing sensitive information from events
by Erwan Viollet 25 Aug '25

25 Aug '25

Hello, I am currently looking into how to remove sensitive information from JFR events. The main events that typically contain sensitive information: jdk.SystemProcess, jdk.InitialSystemProperty, jdk.JVMInformation. Passwords from command lines can typically be found in these events. Dropping these events altogether is not ideal, as we need them to make relevant performance recommendations to users (e.g. suggesting JVM or system setting adjustments). Dropping them or scrubbing them on the backend side (after the fact) requires decompressing and re-writing these events, which is wasteful in terms of both compute and storage. The approach is not perfect, as we still end up intaking and temporarily storing sensitive information. Ideally, we would like to be able to scrub or redact only the sensitive fields within these events (for example, using a simple regex or pattern-based rule), rather than dropping the whole event. We also want to avoid handling this only after the event has already been written to the JFR file, as that does not fully mitigate the risk of exposing sensitive data. At present, it appears there is no public API or supported mechanism to intercept or scrub JFR events in-process, before they are persisted. What would you think of an API accepting custom scrubbing patterns so that sensitive data never leaves the JVM in an unredacted state? Are there any plans or discussions in this area? I am fairly new to the JFR world, so it is likely that I missed previous discussions around this. Thank you, Best regards, Erwan Viollet, Profiling team, Datadog

2 5

RFR: 8358619: Fix interval recomputation in CPU Time Profiler
by Johannes Bechberger 15 Jul '25

15 Jul '25

Fixes the recomputation issue by passing either the rate or the period directly to the sampler (instead of just the rate value with the period value converted into a rate). This prevents issues when the number of cores changes during the JFR recording. ------------- Commit messages: - 8358619: Fix interval recomputation in CPU Time Profiler Changes: https://git.openjdk.org/jdk/pull/25775/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25775&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358619 Stats: 327 lines in 11 files changed: 180 ins; 78 del; 69 mod Patch: https://git.openjdk.org/jdk/pull/25775.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25775/head:pull/25775 PR: https://git.openjdk.org/jdk/pull/25775

5 13

RFR: 8358750: JFR: EventInstrumentation MASK_THROTTLE* constants should be computed in longs
by Erik Gahlin 03 Jul '25

03 Jul '25

Could I have a review of a fix to the throttling mechanism added in JDK 25? Long values should be shifted instead of integer values when creating the masks. During debugging, I found several issues, and I also strengthened the test. - The start time of the event needs to be stored if the event is being throttled. The reason is that the timestamp is reused later to determine if the event should be throttled or not. This happens with events that lack an end time. - The duration value that is written to the buffer must remove the mask if it is throttled. This is handled by`getDuration(blockCodeBuilder)`. - I added a clarifying comment that when duration is compared to 0, it also prevents a new duration from being calculated if the event has been throttled (for an instant event). The test now checks that the duration is not negative, that the start time is not before the test starts, and that the duration is not unreasonably large. The reason I multiply the recording duration by two is to give the test some slack in case we run into clock issues where the time taken for the event doesn't match the recording. Purpose of the check is to make sure we don't end up with the mask being added to the duration. Testing: test/jdk/jdk/jfr I validated manually that the throttle rate works using a small test program I have (which can't be checked in due to stability issues). ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/26028/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26028&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358750 Stats: 78 lines in 2 files changed: 48 ins; 22 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/26028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26028/head:pull/26028 PR: https://git.openjdk.org/jdk/pull/26028

3 4

[jdk25] RFR: 8360287: JFR: PlatformTracer class should be loaded lazily
by Erik Gahlin 03 Jul '25

03 Jul '25

8360287: JFR: PlatformTracer class should be loaded lazily ------------- Commit messages: - Backport 8ea544c33fc502208577249fb83544f8d876bc17 Changes: https://git.openjdk.org/jdk/pull/26040/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26040&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360287 Stats: 75 lines in 4 files changed: 62 ins; 11 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26040.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26040/head:pull/26040 PR: https://git.openjdk.org/jdk/pull/26040

3 4

[jdk25] RFR: 8360201: JFR: Initialize JfrThreadLocal::_sampling_critical_section
by Aleksey Shipilev 30 Jun '25

30 Jun '25

Fixes the bug in the new feature in JDK 25. The fix is pretty trivial. ------------- Commit messages: - Backport 5c1f77fab1f56e470157d8680310417924abb298 Changes: https://git.openjdk.org/jdk/pull/25952/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25952&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360201 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25952.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25952/head:pull/25952 PR: https://git.openjdk.org/jdk/pull/25952

2 4

RFR: 8354310: JFR: Inconsistent metadata in ZPageAllocation
by Joel Sikström 27 Jun '25

27 Jun '25

Hello, This PR fixes JFR metadata for ZPageAllocation after [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441). ------------- Commit messages: - 8354310: JFR: Inconsistent metadata in ZPageAllocation Changes: https://git.openjdk.org/jdk/pull/24578/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24578&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354310 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24578.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24578/head:pull/24578 PR: https://git.openjdk.org/jdk/pull/24578

4 9

RFR: 8360287: JFR: PlatformTracer class should be loaded lazily
by Erik Gahlin 26 Jun '25

26 Jun '25

Could I have a review of a change that ensures that the PlatformTracer and its static initializers are not run unless a method timing or method tracing filter has been set? Testing: test/jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Remove whitespace - Initial Changes: https://git.openjdk.org/jdk/pull/25937/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25937&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360287 Stats: 75 lines in 4 files changed: 62 ins; 11 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25937.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25937/head:pull/25937 PR: https://git.openjdk.org/jdk/pull/25937

2 2

[jdk25] RFR: 8360403: Disable constant pool ID assert during troubleshooting
by Markus Grönlund 24 Jun '25

24 Jun '25

8360403: Disable constant pool ID assert during troubleshooting ------------- Commit messages: - Backport cbcf401170e0600e48ef74770eaa47c84c7e50b0 Changes: https://git.openjdk.org/jdk/pull/25957/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25957&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360403 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25957/head:pull/25957 PR: https://git.openjdk.org/jdk/pull/25957

2 3

RFR: 8360403: Disable constant pool ID assert during troubleshooting
by Markus Grönlund 24 Jun '25

24 Jun '25

Greetings, This is a workaround to disable the assert when the parser encounters a missing constant pool artifact ID, effective only for the duration of the deeper root cause analysis. The workaround is to avoid causing problems for any tests running JFR with -ea and -esa. This bug is a subtask of the main issue that tracks the root cause of the problem and has arisen due to the complexities involved in deep troubleshooting. [JDK-8356587 Missing object ID X in pool jdk.types.Method](https://bugs.openjdk.org/browse/JDK-8356587) Thanks Markus ------------- Commit messages: - 8360403 Changes: https://git.openjdk.org/jdk/pull/25955/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25955&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360403 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25955.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25955/head:pull/25955 PR: https://git.openjdk.org/jdk/pull/25955

2 2