March 2025 - hotspot-jfr-dev

RFR: 8351992: JFR: Improve robustness of the SettingControl examples
by Erik Gahlin 16 Mar '25

16 Mar '25

Could I have a review of PR that improves the robustness of the SettingControl examples. Testing: jdk/jdk/jfr + tier1 Thanks Erik ------------- Commit messages: - Minor changes - Initial Changes: https://git.openjdk.org/jdk/pull/24056/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24056&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351992 Stats: 42 lines in 2 files changed: 31 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/24056.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24056/head:pull/24056 PR: https://git.openjdk.org/jdk/pull/24056

2 2

RFR: 8351266: JFR: -XX:StartFlightRecording:report-on-exit
by Erik Gahlin 13 Mar '25

13 Mar '25

Could I have a review of an enhancement that prints 'jfr view' when the JVM exits? The purpose is to simplify usage and avoid the need to dump to a file. For more details, see the [CSR](https://bugs.openjdk.org/browse/JDK-8351370) Example usage: $ java -XX:StartFlightRecording:report-on-exit=hot-methods ... [0.166s][info][jfr,startup] Started recording 1. No limit specified, using maxsize=250MB as default. [0.166s][info][jfr,startup] [0.166s][info][jfr,startup] Use jcmd 66977 JFR.dump name=1 filename=FILEPATH to copy recording data to file. Java Methods that Executes the Most Method Samples Percent ------------------------------------------------------------------------------------------------------- ------- ------- sun.java2d.marlin.Renderer._endRendering(int, int) 120 33.99% sun.java2d.marlin.MarlinTileGenerator.getAlphaRLE(byte[], int, int) 22 6.23% sun.awt.image.PNGImageDecoder.produceImage() 19 5.38% sun.java2d.marlin.MarlinCache.copyAARowRLE_WithBlockFlags(int[], int[], int, int, int) 14 3.97% sun.java2d.marlin.MarlinTileGenerator.getAlphaNoRLE(byte[], int, int) 7 1.98% sun.java2d.marlin.Renderer.copyAARow(int[], int, int, int, boolean) 7 1.98% sun.awt.image.PNGImageDecoder.filterRow(byte[], byte[], int, int, int) 7 1.98% sun.java2d.marlin.MarlinCache.copyAARowNoRLE(int[], int, int, int) 5 1.42% sun.java2d.pipe.BufferedContext.validate(...) 5 1.42% java.awt.GradientPaintContext.clipFillRaster(int[], int, int, int, int, double, double, double) 3 0.85% Testing: jdk/jdk/jfr ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/23958/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23958&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351266 Stats: 292 lines in 15 files changed: 275 ins; 3 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/23958.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23958/head:pull/23958 PR: https://git.openjdk.org/jdk/pull/23958

2 6

RFR: 8351146: JFR: Reconsider thresholds for monitor-related events
by Aleksey Shipilev 11 Mar '25

11 Mar '25

There are two issues with current thresholds for monitor-related events: 1. The threshold for enter/wait is too high for practical use. @coleenp separately said during related CSR review that 5ms is more practical value: https://bugs.openjdk.org/browse/JDK-8348833?focusedId=14744853#comment-1474… -- I think we should trim those even further. 2. There is a threshold for inflate event. But the operation that is covered by that event is very fast, and often lock-free, so the threshold would filter many events. This would be important as we add deflation event ([JDK-8351142](https://bugs.openjdk.org/browse/JDK-8351142)) which should match inflations. The PR changes `locking-threshold` default, so it affects a few other events as well. I am picking 1ms as the practical value that we usually deal with in production environments, as we chase down single-digit-ms latency hogs. I am open for suggestions about the values, though. Maybe `default.jfc` values should be higher? Additional testing: - [x] Linux x86_64 server fastdebug, `jdk_jfr` still passes ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/23891/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23891&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351146 Stats: 12 lines in 2 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/23891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23891/head:pull/23891 PR: https://git.openjdk.org/jdk/pull/23891

3 11

RFR: 8351064: JFR: Consistent timestamps
by Erik Gahlin 04 Mar '25

04 Mar '25

Could I have review of a PR that makes time conversion uses offsets taken from the first chunk even if user-defined events are registered and parsers are reconstructed. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/23870/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23870&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351064 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23870.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23870/head:pull/23870 PR: https://git.openjdk.org/jdk/pull/23870

2 2