June 2022 - hotspot-jfr-dev

RFR: 8288846: misc tests fail "assert(ms < 1000) failed: Un-interruptable sleep, short time use only"
by Markus Grönlund 22 Jun '22

22 Jun '22

Greetings, this is a small adjustment to rectify the consequence of [JDK-8288663](https://bugs.openjdk.org/browse/JDK-8288663). Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8288846 Changes: https://git.openjdk.org/jdk19/pull/57/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=57&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288846 Stats: 12 lines in 2 files changed: 9 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk19/pull/57.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/57/head:pull/57 PR: https://git.openjdk.org/jdk19/pull/57

2 4

RFR: 8288741: JFR: Change package name of snippet files
by Erik Gahlin 20 Jun '22

20 Jun '22

Could I have a review of PR that changes package names of the JFR snippet files. Today they are named "example1" and "example2" in the default package. It looks strange when browsing classes in jrt-fs.jar, for example in Eclipse. Not sure why they are included at all. New names will be "jdk.jfr.snippets" and "jdk.jfr.snippets.consumer" Testing: build docs + tier1 + tier2 Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk19/pull/46/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=46&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288741 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk19/pull/46.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/46/head:pull/46 PR: https://git.openjdk.org/jdk19/pull/46

2 2

RFR: 8288663: JFR: Disabling the JfrThreadSampler commits only a partially disabled state
by Markus Grönlund 20 Jun '22

20 Jun '22

8288663: JFR: Disabling the JfrThreadSampler commits only a partially disabled state ------------- Commit messages: - Backport a7df5a40639a4d3138616c9fc1b144381240d2e5 Changes: https://git.openjdk.org/jdk19/pull/45/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=45&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288663 Stats: 122 lines in 7 files changed: 47 ins; 19 del; 56 mod Patch: https://git.openjdk.org/jdk19/pull/45.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/45/head:pull/45 PR: https://git.openjdk.org/jdk19/pull/45

1 1

RFR: 8288663: JFR: Disabling the JfrThreadSampler commits only a partially disabled state
by Markus Grönlund 20 Jun '22

20 Jun '22

Greetings, please review the following change set. The problematic situation is described in the JIRA issue. In addition, I have taken the opportunity to align "interval" with "period", since the concept is exported and used more pervasively. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - typo - 8288663 Changes: https://git.openjdk.org/jdk/pull/9199/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9199&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288663 Stats: 123 lines in 7 files changed: 47 ins; 19 del; 57 mod Patch: https://git.openjdk.org/jdk/pull/9199.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9199/head:pull/9199 PR: https://git.openjdk.org/jdk/pull/9199

3 6

RFR: 8287800: JFR: Incorrect error message when starting recording with missing .jfc file
by Erik Gahlin 20 Jun '22

20 Jun '22

Could I have review of PR that fixes incorrect error messages when starting a recording. The current message is very confusing. If a user types`jcmd <pid> JFR.start settings=my.jfc`, but doesn't realise that the path should be relative to where the JVM started, the error message says "Could not parse settings file custom.jfc" It should say "Could not **find** file custom.jfc" Furthermore, if a user specifies `settings=default.jfc settings=my.jfc`to get settings from two files, the error message will say "Could not parse file default.jfc", even though it was my.jfc it was unable to find. This problem impacts `jfr configure`, `-XX:StartFlightRecording` and `JFR.start`. Code has been refactored so error formatting now happens per file and in one place with a proper verb ("find", "parse", "use", "access", "open"). Error messages from the parser are also propagated, for example: "Could not parse file 'my.jfc". Expected root element to be named 'configuration'" Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Fix whitespace - Initial Changes: https://git.openjdk.org/jdk19/pull/43/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=43&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287800 Stats: 225 lines in 14 files changed: 101 ins; 52 del; 72 mod Patch: https://git.openjdk.org/jdk19/pull/43.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/43/head:pull/43 PR: https://git.openjdk.org/jdk19/pull/43

2 2

RFR: 8288685 JFR: Use static methods for Active Recording and Active Setting events
by Erik Gahlin 20 Jun '22

20 Jun '22

Could I have a review of PR that ensures that Active Recording and Active Setting events have the same timestamp. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/9206/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9206&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288685 Stats: 49 lines in 4 files changed: 22 ins; 13 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/9206.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9206/head:pull/9206 PR: https://git.openjdk.org/jdk/pull/9206

3 4

RFR: 8285519: Simplify TimeUnit.convert calls
by Andrey Turbanov 16 Jun '22

16 Jun '22

TimeUnit.toMillis/toNanos/toMicros/toSeconds is shorter and a bit faster. Compared via JMH benchmark: 150ns -> 125ns/op <details> <summary>Benchamark adapted from http://cr.openjdk.java.net/~shade/8152083/TimeUnitBench.java</summary> @Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS) @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS) @Fork(1) @State(Scope.Thread) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class TimeUnitBench { static final int SIZE = TimeUnit.values().length * 10; @Param({"0", "1", "2", "3", "4", "5", "6", "-1"}) int bias; TimeUnit[] mod; @Setup public void setup() { mod = new TimeUnit[SIZE]; TimeUnit[] vals = TimeUnit.values(); for (int c = 0; c < SIZE; c++) { if (bias == -1) { // megamorphic mod[c] = vals[c % vals.length]; } else { mod[c] = vals[bias]; } } Random r = new Random(); for (int c = 0; c < 10000; c++) { int i = r.nextInt(); for (int o = 0; o < vals.length; o++) { if (vals[o].toNanos(i) != TimeUnit.NANOSECONDS.convert(i, vals[o])) throw new IllegalStateException("switch " + o); } } } @Benchmark public void const_convert(Blackhole bh) { for (TimeUnit tu : mod) { bh.consume(do_convert(tu)); } } @Benchmark public void value_convert(Blackhole bh) { for (TimeUnit tu : mod) { bh.consume(do_convert(tu, 1L)); } } @Benchmark public void const_toNanos(Blackhole bh) { for (TimeUnit tu : mod) { bh.consume(do_toNanos(tu)); } } @Benchmark public void value_toNanos(Blackhole bh) { for (TimeUnit tu : mod) { bh.consume(do_toNanos(tu, 1L)); } } @CompilerControl(CompilerControl.Mode.DONT_INLINE) private long do_toNanos(TimeUnit tu) { return tu.toNanos(1L); } @CompilerControl(CompilerControl.Mode.DONT_INLINE) private long do_toNanos(TimeUnit tu, long value) { return tu.toNanos(value); } @CompilerControl(CompilerControl.Mode.DONT_INLINE) private long do_convert(TimeUnit tu) { return TimeUnit.NANOSECONDS.convert(1L, tu); } @CompilerControl(CompilerControl.Mode.DONT_INLINE) private long do_convert(TimeUnit tu, long value) { return TimeUnit.NANOSECONDS.convert(value, tu); } } Results: Benchmark (bias) Mode Cnt Score Error Units TimeUnitBench.const_convert 0 avgt 5 151,856 ± 28,595 ns/op TimeUnitBench.const_convert 1 avgt 5 150,720 ± 23,863 ns/op TimeUnitBench.const_convert 2 avgt 5 151,432 ± 23,184 ns/op TimeUnitBench.const_convert 3 avgt 5 150,959 ± 24,726 ns/op TimeUnitBench.const_convert 4 avgt 5 150,966 ± 25,280 ns/op TimeUnitBench.const_convert 5 avgt 5 150,976 ± 25,542 ns/op TimeUnitBench.const_convert 6 avgt 5 151,118 ± 25,254 ns/op TimeUnitBench.const_convert -1 avgt 5 152,673 ± 29,861 ns/op TimeUnitBench.const_toNanos 0 avgt 5 121,296 ± 25,236 ns/op TimeUnitBench.const_toNanos 1 avgt 5 121,707 ± 25,364 ns/op TimeUnitBench.const_toNanos 2 avgt 5 121,736 ± 25,726 ns/op TimeUnitBench.const_toNanos 3 avgt 5 121,822 ± 25,491 ns/op TimeUnitBench.const_toNanos 4 avgt 5 121,867 ± 26,090 ns/op TimeUnitBench.const_toNanos 5 avgt 5 121,927 ± 25,611 ns/op TimeUnitBench.const_toNanos 6 avgt 5 121,821 ± 25,843 ns/op TimeUnitBench.const_toNanos -1 avgt 5 121,923 ± 25,206 ns/op TimeUnitBench.value_convert 0 avgt 5 150,525 ± 25,439 ns/op TimeUnitBench.value_convert 1 avgt 5 151,098 ± 24,024 ns/op TimeUnitBench.value_convert 2 avgt 5 151,259 ± 25,381 ns/op TimeUnitBench.value_convert 3 avgt 5 151,030 ± 25,548 ns/op TimeUnitBench.value_convert 4 avgt 5 151,290 ± 25,998 ns/op TimeUnitBench.value_convert 5 avgt 5 151,006 ± 25,448 ns/op TimeUnitBench.value_convert 6 avgt 5 150,945 ± 25,314 ns/op TimeUnitBench.value_convert -1 avgt 5 151,186 ± 25,814 ns/op TimeUnitBench.value_toNanos 0 avgt 5 121,556 ± 25,745 ns/op TimeUnitBench.value_toNanos 1 avgt 5 123,410 ± 22,323 ns/op TimeUnitBench.value_toNanos 2 avgt 5 125,452 ± 26,575 ns/op TimeUnitBench.value_toNanos 3 avgt 5 125,297 ± 26,204 ns/op TimeUnitBench.value_toNanos 4 avgt 5 125,357 ± 26,085 ns/op TimeUnitBench.value_toNanos 5 avgt 5 125,165 ± 26,185 ns/op TimeUnitBench.value_toNanos 6 avgt 5 125,536 ± 25,487 ns/op TimeUnitBench.value_toNanos -1 avgt 5 125,460 ± 25,063 ns/op </details> ------------- Commit messages: - [PATCH] Simplify TimeUnit.convert calls to TimeUnit.toSomething instead Changes: https://git.openjdk.java.net/jdk/pull/8376/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8376&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285519 Stats: 30 lines in 7 files changed: 2 ins; 0 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/8376.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8376/head:pull/8376 PR: https://git.openjdk.java.net/jdk/pull/8376

3 5

RFR: 8288289: Preview APIs in jdk.jdi, jdk.management, and jdk.jfr should be reflective preview APIs
by Alan Bateman 15 Jun '22

15 Jun '22

A number of the preview APIs added by JEP 425 exist to expose and support the virtual threads preview feature. Some of these APIs should be changed to be reflective preview APIs (see JEP 12). This will allow debuggers and other tooling to get a jump on virtual threads without opting in themselves. ------------- Commit messages: - HotSpotDiagnosticMXBean.dumpThreads should be reflective too - Merge - Initial commit Changes: https://git.openjdk.org/jdk19/pull/13/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=13&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288289 Stats: 6 lines in 5 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk19/pull/13.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/13/head:pull/13 PR: https://git.openjdk.org/jdk19/pull/13

3 3

RFR: 8287811: JFR: jfr configure error message should not print stack trace
by Erik Gahlin 07 Jun '22

07 Jun '22

Could I have a review of PR that removes a printStackTrace() for the jfr tool. Testing: jdk/jfr/tool Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/9018/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9018&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287811 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/9018.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9018/head:pull/9018 PR: https://git.openjdk.java.net/jdk/pull/9018

2 2

RFR: 8287799: JFR: Less noisy platform threads with jfr print
by Erik Gahlin 07 Jun '22

07 Jun '22

Could I have review of a PR that removes "virtual = false" from 'jfr print' if the thread is a platform thread. In case of a virtual thread, it should be sufficient to have "virtual" after the thread ID. Testing: jdk/jdk/jfr + manual check of output for virtual and platform threads Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/9014/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9014&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287799 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/9014.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9014/head:pull/9014 PR: https://git.openjdk.java.net/jdk/pull/9014

2 2