July 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: 8359690: New test TestCPUTimeSampleThrottling still fails intermittently
by Johannes Bechberger 07 Aug '25

07 Aug '25

This change fixes the issue by making the test independent of the system load. Tested both with high and low load. ------------- Commit messages: - Make TestCPUTimeSampleThrottling machine load independent Changes: https://git.openjdk.org/jdk/pull/26506/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26506&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8359690 Stats: 15 lines in 1 file changed: 3 ins; 7 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26506.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26506/head:pull/26506 PR: https://git.openjdk.org/jdk/pull/26506

2 4

RFR: 8364316: JFR: Incorrect validation of mirror fields
by Erik Gahlin 04 Aug '25

04 Aug '25

Could I please have a review of a PR that fixes a bug in the mirror field validation? Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/26539/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26539&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364316 Stats: 9 lines in 1 file changed: 4 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26539.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26539/head:pull/26539 PR: https://git.openjdk.org/jdk/pull/26539

3 6

RFR: 8364190: JFR: RemoteRecordingStream withers don't work
by Erik Gahlin 04 Aug '25

04 Aug '25

Could I please have a review of a PR that fixes the RemoteRecordingStream::with-methods? Testing: test/jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/26540/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26540&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364190 Stats: 151 lines in 3 files changed: 143 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/26540.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26540/head:pull/26540 PR: https://git.openjdk.org/jdk/pull/26540

3 3

RFR: 8364461: JFR: Default constructor may not be first in setting control
by Erik Gahlin 04 Aug '25

04 Aug '25

Could I have a review of a PR that fixes a bug occurring when a user-defined setting does not have the default constructor first? Test: test/jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/26582/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26582&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364461 Stats: 28 lines in 2 files changed: 20 ins; 7 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26582.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26582/head:pull/26582 PR: https://git.openjdk.org/jdk/pull/26582

2 2

RFR: 8364427: JFR: Possible resource leak in Recording::getStream
by Erik Gahlin 04 Aug '25

04 Aug '25

Could I have a review of the PR that fixes resource leaks when Recording::getStream is used? Testing: tier1 + test/jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Fix whitespace - Initial Changes: https://git.openjdk.org/jdk/pull/26575/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26575&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364427 Stats: 176 lines in 2 files changed: 160 ins; 6 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/26575.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26575/head:pull/26575 PR: https://git.openjdk.org/jdk/pull/26575

3 7

RFR: 8364257: JFR: User-defined events and settings with a one-letter name cannot be configured
by Erik Gahlin 04 Aug '25

04 Aug '25

Could I have a review of the PR that fixes a bug with short event or setting names? Instead of adding a new test, I modified an existing test so that it uses an event and setting name with one letter. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/26531/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26531&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364257 Stats: 10 lines in 2 files changed: 4 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26531.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26531/head:pull/26531 PR: https://git.openjdk.org/jdk/pull/26531

2 2

Re: RFR: 8364258: ThreadGroup constant pool serialization is not normalized [v6]
by Markus Grönlund 01 Aug '25

01 Aug '25

> Greetings, > > The following change set normalizes the ThreadGroup constants being serialized to the .jfr binary file. > > It does this in two parts: > > 1. Re-inserts a scavenging scheme to remove stale (unloaded) ThreadGroups; some logic that we used to have in place, but may have been lost as part of the major refactoring around JFR Event Streaming, or even earlier. > 2. Introduces a per-epoch "is_serialized" scheme, building on top of JFR epoch generations. > > Problem manifestation is a very high number of duplicated TGs (jdk.types.ThreadGroup) as part of JFR checkpoints. > > Testing: jdk_jfr > > Thanks > Markus Markus Grönlund has updated the pull request incrementally with one additional commit since the last revision: minimal window ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26558/files - new: https://git.openjdk.org/jdk/pull/26558/files/0691e4c5..c73a8f91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=04-05 Stats: 10 lines in 3 files changed: 1 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26558.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26558/head:pull/26558 PR: https://git.openjdk.org/jdk/pull/26558

2 1

Re: RFR: 8364258: ThreadGroup constant pool serialization is not normalized [v5]
by Markus Grönlund 31 Jul '25

31 Jul '25

> Greetings, > > The following change set normalizes the ThreadGroup constants being serialized to the .jfr binary file. > > It does this in two parts: > > 1. Re-inserts a scavenging scheme to remove stale (unloaded) ThreadGroups; some logic that we used to have in place, but may have been lost as part of the major refactoring around JFR Event Streaming, or even earlier. > 2. Introduces a per-epoch "is_serialized" scheme, building on top of JFR epoch generations. > > Problem manifestation is a very high number of duplicated TGs (jdk.types.ThreadGroup) as part of JFR checkpoints. > > Testing: jdk_jfr > > Thanks > Markus Markus Grönlund has updated the pull request incrementally with one additional commit since the last revision: adjustment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26558/files - new: https://git.openjdk.org/jdk/pull/26558/files/e973f67b..0691e4c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26558.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26558/head:pull/26558 PR: https://git.openjdk.org/jdk/pull/26558

1 0