From shade at openjdk.java.net Thu Jan 7 11:03:09 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 7 Jan 2021 11:03:09 GMT Subject: RFR: CODETOOLS-7902818: JMH: Remove Hotspot-specific MBeans profilers Message-ID: <1qWeQe-UppKGQoOm_fq8dPdSYwKJWgjEdpW-YS-_AgA=.0003dd1f-b106-468f-a849-45d02550062b@github.com> JDK 16 [strengthens the access to internal JDK classes](https://openjdk.java.net/jeps/396), and therefore internal Hotspot-specific MBeans are not easily accessible anymore. So the hs_* profilers that existed from Day 1 in JMH are not working. These profilers are seldom (never?) used, and their functionality is better covered by JFR profilers. So, it makes sense to just ditch these profilers from JMH. ------------- Commit messages: - CODETOOLS-7902818: JMH: Remove Hotspot-specific MBeans profilers Changes: https://git.openjdk.java.net/jmh/pull/17/files Webrev: https://webrevs.openjdk.java.net/?repo=jmh&pr=17&range=00 Issue: https://bugs.openjdk.java.net/browse/CODETOOLS-7902818 Stats: 810 lines in 12 files changed: 0 ins; 810 del; 0 mod Patch: https://git.openjdk.java.net/jmh/pull/17.diff Fetch: git fetch https://git.openjdk.java.net/jmh pull/17/head:pull/17 PR: https://git.openjdk.java.net/jmh/pull/17 From shade at redhat.com Thu Jan 7 11:10:31 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 Jan 2021 12:10:31 +0100 Subject: hs_gc profiler not working on JDK 17 In-Reply-To: <2d4580b9-b018-2259-38b0-ad4fe5908400@gmx.net> References: <2d4580b9-b018-2259-38b0-ad4fe5908400@gmx.net> Message-ID: Hi, On 12/16/20 7:39 PM, Philippe Marschall wrote: > I am using JMH 1.27 on a local JDK 17 / master build and can not get the > hs_gc profiler to work. Initially I got illegal access warnings, I > assume due to JEP 396 [1]. I managed to get them fixed using > > --add-exports java.management/sun.management=ALL-UNNAMED > --add-opens java.management/sun.management=ALL-UNNAMED Yeah, those look hard to salvage, to be honest. So it seems better to remove them: https://bugs.openjdk.java.net/browse/CODETOOLS-7902818 Use -prof jfr, if you need advanced VM data. > I am running on a local JDK 17 / master build because I am working on a > JDK pull request and was asked to provide a microbenchmark. Right. What metrics exactly were you looking for in hs_gc profiler? -- Thanks, -Aleksey From duke at openjdk.java.net Thu Jan 7 11:26:51 2021 From: duke at openjdk.java.net (duke) Date: Thu, 7 Jan 2021 11:26:51 GMT Subject: git: openjdk/jmh: CODETOOLS-7902818: JMH: Remove Hotspot-specific MBeans profilers (#17) Message-ID: <80b633e9-af31-4673-aa56-74f9a916944a@openjdk.java.net> Changeset: 2354a38e Author: Aleksey Shipil?v Committer: GitHub Date: 2021-01-07 12:26:19 +0000 URL: https://git.openjdk.java.net/jmh/commit/2354a38e CODETOOLS-7902818: JMH: Remove Hotspot-specific MBeans profilers (#17) - jmh-core-it/src/test/java/org/openjdk/jmh/it/profilers/HotspotClassloadingProfilerTest.java - jmh-core-it/src/test/java/org/openjdk/jmh/it/profilers/HotspotCompilationProfilerTest.java - jmh-core-it/src/test/java/org/openjdk/jmh/it/profilers/HotspotMemoryProfilerTest.java - jmh-core-it/src/test/java/org/openjdk/jmh/it/profilers/HotspotRuntimeProfilerTest.java - jmh-core-it/src/test/java/org/openjdk/jmh/it/profilers/HotspotThreadProfilerTest.java - jmh-core/src/main/java/org/openjdk/jmh/profile/AbstractHotspotProfiler.java - jmh-core/src/main/java/org/openjdk/jmh/profile/HotspotClassloadingProfiler.java - jmh-core/src/main/java/org/openjdk/jmh/profile/HotspotCompilationProfiler.java - jmh-core/src/main/java/org/openjdk/jmh/profile/HotspotMemoryProfiler.java - jmh-core/src/main/java/org/openjdk/jmh/profile/HotspotRuntimeProfiler.java - jmh-core/src/main/java/org/openjdk/jmh/profile/HotspotThreadProfiler.java ! jmh-core/src/main/java/org/openjdk/jmh/profile/ProfilerFactory.java From shade at openjdk.java.net Thu Jan 7 11:30:04 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 7 Jan 2021 11:30:04 GMT Subject: Withdrawn: CODETOOLS-7902818: JMH: Remove Hotspot-specific MBeans profilers In-Reply-To: <1qWeQe-UppKGQoOm_fq8dPdSYwKJWgjEdpW-YS-_AgA=.0003dd1f-b106-468f-a849-45d02550062b@github.com> References: <1qWeQe-UppKGQoOm_fq8dPdSYwKJWgjEdpW-YS-_AgA=.0003dd1f-b106-468f-a849-45d02550062b@github.com> Message-ID: On Thu, 7 Jan 2021 10:57:20 GMT, Aleksey Shipilev wrote: > JDK 16 [strengthens the access to internal JDK classes](https://openjdk.java.net/jeps/396), and therefore internal Hotspot-specific MBeans are not easily accessible anymore. So the hs_* profilers that existed from Day 1 in JMH are not working. These profilers are seldom (never?) used, and their functionality is better covered by JFR profilers. > > So, it makes sense to just ditch these profilers from JMH. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jmh/pull/17 From henri.tremblay at gmail.com Thu Jan 7 15:21:25 2021 From: henri.tremblay at gmail.com (Henri Tremblay) Date: Thu, 7 Jan 2021 10:21:25 -0500 Subject: Withdrawn: CODETOOLS-7902818: JMH: Remove Hotspot-specific MBeans profilers In-Reply-To: References: <1qWeQe-UppKGQoOm_fq8dPdSYwKJWgjEdpW-YS-_AgA=.0003dd1f-b106-468f-a849-45d02550062b@github.com> Message-ID: Every time I see these things being removed from access I get sadder and sadder... And why on Earth should JFR be allowed to do things that other profilers can't. The strength of Java comes from allowing people to fool around. If we would not be able to do everything we did all these years, there would be no Java anymore. On Thu, 7 Jan 2021 at 06:30, Aleksey Shipilev wrote: > On Thu, 7 Jan 2021 10:57:20 GMT, Aleksey Shipilev > wrote: > > > JDK 16 [strengthens the access to internal JDK classes]( > https://openjdk.java.net/jeps/396), and therefore internal > Hotspot-specific MBeans are not easily accessible anymore. So the hs_* > profilers that existed from Day 1 in JMH are not working. These profilers > are seldom (never?) used, and their functionality is better covered by JFR > profilers. > > > > So, it makes sense to just ditch these profilers from JMH. > > This pull request has been closed without being integrated. > > ------------- > > PR: https://git.openjdk.java.net/jmh/pull/17 > From kustos at gmx.net Sun Jan 10 09:37:54 2021 From: kustos at gmx.net (Philippe Marschall) Date: Sun, 10 Jan 2021 10:37:54 +0100 Subject: hs_gc profiler not working on JDK 17 In-Reply-To: References: <2d4580b9-b018-2259-38b0-ad4fe5908400@gmx.net> Message-ID: <5edc6869-67f2-a931-751a-48960f944e1d@gmx.net> On 07.01.21 12:10, Aleksey Shipilev wrote: > ... > >> I am running on a local JDK 17 / master build because I am working on a >> JDK pull request and was asked to provide a microbenchmark. > > Right. What metrics exactly were you looking for in hs_gc profiler? > The "gc" profiler ended up being good enough. It would have been nice to know how many slow path allocations we are hitting (outside TLAB, humongous) but I'm not sure "hs_gc" can provide those and I would have to use the JFR profiler anyway. Cheers Philippe From shade at openjdk.java.net Wed Jan 13 12:07:11 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 13 Jan 2021 12:07:11 GMT Subject: RFR: CODETOOLS-7902813: Amend experimental compiler-assisted blackhole support Message-ID: JDK-8258619 changes the requirements for compiler-assisted blackholes to be empty static methods. This requires adjustments to JMH Blackhole itself. ------------- Commit messages: - CODETOOLS-7902813: Amend experimental compiler-assisted blackhole support Changes: https://git.openjdk.java.net/jmh/pull/16/files Webrev: https://webrevs.openjdk.java.net/?repo=jmh&pr=16&range=00 Issue: https://bugs.openjdk.java.net/browse/CODETOOLS-7902813 Stats: 206 lines in 4 files changed: 126 ins; 33 del; 47 mod Patch: https://git.openjdk.java.net/jmh/pull/16.diff Fetch: git fetch https://git.openjdk.java.net/jmh pull/16/head:pull/16 PR: https://git.openjdk.java.net/jmh/pull/16 From shade at openjdk.java.net Wed Jan 13 12:12:15 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 13 Jan 2021 12:12:15 GMT Subject: RFR: CODETOOLS-7902813: Amend experimental compiler-assisted blackhole support [v2] In-Reply-To: References: Message-ID: > JDK-8258619 changes the requirements for compiler-assisted blackholes to be empty static methods. This requires adjustments to JMH Blackhole itself. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Cleanup before integration ------------- Changes: - all: https://git.openjdk.java.net/jmh/pull/16/files - new: https://git.openjdk.java.net/jmh/pull/16/files/bfb02869..796449c9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmh&pr=16&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmh&pr=16&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jmh/pull/16.diff Fetch: git fetch https://git.openjdk.java.net/jmh pull/16/head:pull/16 PR: https://git.openjdk.java.net/jmh/pull/16 From duke at openjdk.java.net Wed Jan 13 15:10:20 2021 From: duke at openjdk.java.net (duke) Date: Wed, 13 Jan 2021 15:10:20 GMT Subject: git: openjdk/jmh: CODETOOLS-7902813: Amend experimental compiler-assisted blackhole support (#16) Message-ID: Changeset: 662743e7 Author: Aleksey Shipil?v Committer: GitHub Date: 2021-01-13 16:09:38 +0000 URL: https://git.openjdk.java.net/jmh/commit/662743e7 CODETOOLS-7902813: Amend experimental compiler-assisted blackhole support (#16) ! jmh-core-benchmarks/src/main/java/org/openjdk/jmh/validation/Main.java ! jmh-core-benchmarks/src/main/java/org/openjdk/jmh/validation/tests/BlackholeSingleTest.java ! jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java ! jmh-core/src/main/java/org/openjdk/jmh/runner/CompilerHints.java From shade at openjdk.java.net Wed Jan 13 15:12:09 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 13 Jan 2021 15:12:09 GMT Subject: Withdrawn: CODETOOLS-7902813: Amend experimental compiler-assisted blackhole support In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 18:03:58 GMT, Aleksey Shipilev wrote: > JDK-8258619 changes the requirements for compiler-assisted blackholes to be empty static methods. This requires adjustments to JMH Blackhole itself. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jmh/pull/16 From shade at openjdk.java.net Thu Jan 14 10:24:18 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 14 Jan 2021 10:24:18 GMT Subject: RFR: CODETOOLS-7902695: JMH should not try to access inaccessible fields Message-ID: JDK 9+ reluctantly allows accessing `Console.cs` field to get the console encoding for e.g. Windows. JDK 16+ disallows it point-blank. JDK 9+ still prints the warning. Given that we would not be able to do this in future, it makes sense to check for field accessibility before trying to `setAccessible` the field for JDK 9+. ------------- Commit messages: - Trying to shun the warnings Changes: https://git.openjdk.java.net/jmh/pull/18/files Webrev: https://webrevs.openjdk.java.net/?repo=jmh&pr=18&range=00 Issue: https://bugs.openjdk.java.net/browse/CODETOOLS-7902695 Stats: 23 lines in 1 file changed: 20 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jmh/pull/18.diff Fetch: git fetch https://git.openjdk.java.net/jmh pull/18/head:pull/18 PR: https://git.openjdk.java.net/jmh/pull/18 From shade at openjdk.java.net Thu Jan 14 10:46:19 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 14 Jan 2021 10:46:19 GMT Subject: RFR: CODETOOLS-7902695: JMH should not try to access inaccessible fields [v2] In-Reply-To: References: Message-ID: > JDK 9+ reluctantly allows accessing `Console.cs` field to get the console encoding for e.g. Windows. JDK 16+ disallows it point-blank. JDK 9+ still prints the warning. Given that we would not be able to do this in future, it makes sense to check for field accessibility before trying to `setAccessible` the field for JDK 9+. Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: - Allow breaking in with jmh.forceSetAccessible - Fix up comments ------------- Changes: - all: https://git.openjdk.java.net/jmh/pull/18/files - new: https://git.openjdk.java.net/jmh/pull/18/files/6ab68e2b..7239912c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmh&pr=18&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmh&pr=18&range=00-01 Stats: 15 lines in 1 file changed: 7 ins; 3 del; 5 mod Patch: https://git.openjdk.java.net/jmh/pull/18.diff Fetch: git fetch https://git.openjdk.java.net/jmh pull/18/head:pull/18 PR: https://git.openjdk.java.net/jmh/pull/18 From duke at openjdk.java.net Thu Jan 14 11:17:40 2021 From: duke at openjdk.java.net (duke) Date: Thu, 14 Jan 2021 11:17:40 GMT Subject: git: openjdk/jmh: CODETOOLS-7902695: JMH should not try to access inaccessible fields (#18) Message-ID: <1de71042-fc34-4c14-9b67-7a8de544241a@openjdk.java.net> Changeset: 0cb36802 Author: Aleksey Shipil?v Committer: GitHub Date: 2021-01-14 12:17:11 +0000 URL: https://git.openjdk.java.net/jmh/commit/0cb36802 CODETOOLS-7902695: JMH should not try to access inaccessible fields (#18) ! jmh-core/src/main/java/org/openjdk/jmh/util/Utils.java From shade at openjdk.java.net Thu Jan 14 11:21:06 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 14 Jan 2021 11:21:06 GMT Subject: Withdrawn: CODETOOLS-7902695: JMH should not try to access inaccessible fields In-Reply-To: References: Message-ID: On Thu, 14 Jan 2021 10:21:01 GMT, Aleksey Shipilev wrote: > JDK 9+ reluctantly allows accessing `Console.cs` field to get the console encoding for e.g. Windows. JDK 16+ disallows it point-blank. JDK 9+ still prints the warning. Given that we would not be able to do this in future, it makes sense to check for field accessibility before trying to `setAccessible` the field for JDK 9+. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jmh/pull/18 From henri.tremblay at gmail.com Thu Jan 14 14:45:17 2021 From: henri.tremblay at gmail.com (Henri Tremblay) Date: Thu, 14 Jan 2021 09:45:17 -0500 Subject: Withdrawn: CODETOOLS-7902695: JMH should not try to access inaccessible fields In-Reply-To: References:

Message-ID: Aleysey, just curious, why do we always get "This pull request has been closed without being integrated" if the PR is actually merged? On Thu, 14 Jan 2021 at 06:21, Aleksey Shipilev wrote: > On Thu, 14 Jan 2021 10:21:01 GMT, Aleksey Shipilev > wrote: > > > JDK 9+ reluctantly allows accessing `Console.cs` field to get the > console encoding for e.g. Windows. JDK 16+ disallows it point-blank. JDK 9+ > still prints the warning. Given that we would not be able to do this in > future, it makes sense to check for field accessibility before trying to > `setAccessible` the field for JDK 9+. > > This pull request has been closed without being integrated. > > ------------- > > PR: https://git.openjdk.java.net/jmh/pull/18 > From paul.sandoz at oracle.com Mon Jan 25 17:16:53 2021 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 25 Jan 2021 17:16:53 +0000 Subject: Issues with dtraceasm, and a workaround Message-ID: <6195DE75-60B5-442A-8816-AB78574C64F8@oracle.com> Hi, Numerous Mac users are having issues with dtraceasm. This may be complicated by SIP, although I have it enabled and can get dtraceasm to work. Digging a little deeper I observed that the dtrace process does not like being destroyed (as in Process.destroy()) by the Java process. Some dtrace output is initially present in the output file (tailing the file). When the dtrace process is destroyed it returns an error code of 141, and no further output is present in the output file. I believe error code 141 is associated with the dtrace process receiving a SIGPIPE signal. Sending a TERM signal before destroying the process works around this issue (see patch below). It kicks the dtrace process, resulting in the process relinquishing the remaining dtrace output to the output file. I don?t know why this works, but perhaps this information and the workaround will help others work out what is going on, so a proper fix can be proposed? Paul. diff --git a/jmh-core/src/main/java/org/openjdk/jmh/profile/DTraceAsmProfiler.java b/jmh-core/src/main/java/org/openjdk/jmh/profile/DTraceAsmProfiler.java index 34f67941..0d6fba58 100644 --- a/jmh-core/src/main/java/org/openjdk/jmh/profile/DTraceAsmProfiler.java +++ b/jmh-core/src/main/java/org/openjdk/jmh/profile/DTraceAsmProfiler.java @@ -87,6 +87,9 @@ public class DTraceAsmProfiler extends AbstractPerfAsmProfiler { throw new IllegalStateException("DTrace needs the forked VM PID, but it is not initialized"); } + long dtracePid = dtraceProcess.pid(); + Utils.tryWith("sudo", "kill", "-15", Long.toString(dtracePid)); + Collection messages = Utils.destroy(dtraceProcess); if (!messages.isEmpty()) { throw new IllegalStateException(messages.toString()); diff --git a/jmh-core/src/main/java/org/openjdk/jmh/util/Utils.java b/jmh-core/src/main/java/org/openjdk/jmh/util/Utils.java index fc8c10c7..1ee0db4f 100644 --- a/jmh-core/src/main/java/org/openjdk/jmh/util/Utils.java +++ b/jmh-core/src/main/java/org/openjdk/jmh/util/Utils.java @@ -488,6 +488,7 @@ public class Utils { return Collections.emptyList(); } + messages.add("DTrace exit code: " + exitCode); messages.add(baos.toString()); return messages; } catch (InterruptedException e) { From denys.makogon at oracle.com Fri Jan 22 20:38:31 2021 From: denys.makogon at oracle.com (Denys Makogon) Date: Fri, 22 Jan 2021 20:38:31 +0000 Subject: Issues running benchmarks with dtraceasm profile enabled on macOS Message-ID: Greetings to All! Recently I tried to run the benchmark against a very simple Vectors API code snipped borrowed from corresponding JEP, but unfortunately, I encountered a problem with JMH dtraceasm profile on macOS: Processing profiler results: DTraceAsmProfiler Exception in thread "main" java.lang.IllegalStateException: [] at org.openjdk.jmh.profile.DTraceAsmProfiler.afterTrial(DTraceAsmProfiler.java:92) at org.openjdk.jmh.runner.Runner.runSeparate(Runner.java:689) at org.openjdk.jmh.runner.Runner.runBenchmarks(Runner.java:572) at org.openjdk.jmh.runner.Runner.internalRun(Runner.java:324) at org.openjdk.jmh.runner.Runner.run(Runner.java:210) at org.openjdk.jmh.Main.main(Main.java:71) Code snippet is not provided with this email because it doesn't do anything really special and a given issue was reproduced with other benchmarks. System information: Darwin Deniss-MBP.Dlink 18.7.0 Darwin Kernel Version 18.7.0: Thu Jun 18 20:50:10 PDT 2020; root:xnu-4903.278.43~1/RELEASE_X86_64 x86_64 JDK 16 JMH 1.27 So, is this a known issue or something new? I'd be grateful for any support/advice. Kind regards, Denys Makogon From mca.schenk at googlemail.com Tue Jan 26 06:43:01 2021 From: mca.schenk at googlemail.com (Mark Schenk) Date: Tue, 26 Jan 2021 07:43:01 +0100 Subject: Evaluation benchmark results Message-ID: Dear sir/madam, I'm wondering whether there is a way within JMH to evaluate the scores of the benchmark run results? What I would like to do is during my test check whether the score is below a specified max, and if not, have the build fail. With kind regards, Mark Schenk From henri.tremblay at gmail.com Tue Jan 26 14:22:01 2021 From: henri.tremblay at gmail.com (Henri Tremblay) Date: Tue, 26 Jan 2021 09:22:01 -0500 Subject: Evaluation benchmark results In-Reply-To: References: Message-ID: Hi, You can export the result in multiple formats. So grepping, checking and failing should be fairly easy. Regards, Henri On Tue, 26 Jan 2021 at 06:45, Mark Schenk wrote: > Dear sir/madam, > > I'm wondering whether there is a way within JMH to evaluate the scores of > the benchmark run results? What I would like to do is during my test check > whether the score is below a specified max, and if not, have the build > fail. > > With kind regards, > Mark Schenk >