From mark.web.mail at gmail.com Thu Oct 1 13:25:52 2020 From: mark.web.mail at gmail.com (Mark Price) Date: Thu, 1 Oct 2020 14:25:52 +0100 Subject: Patch: Integrate async-profiler In-Reply-To: <35d7ceac-c50b-a6cf-5747-d072545ce867@redhat.com> References: <5ab55bb0-9edf-04d7-a2a3-165e1315ecd5@redhat.com> <35d7ceac-c50b-a6cf-5747-d072545ce867@redhat.com> Message-ID: Hi folks, thanks for the work on including async-profiler support. I'm seeing some samples from warm-up iterations in the generated output, but it looks as though the intent is to effectively trash the samples from the warm-up phase: if (!measurementStarted) { // Discard samples collected during warmup and start collecting again. execute("start," + profilerConfig); measurementStarted = true; } Verbose debugging shows that the profiler is started twice (as expected), but I suspect the second 'start' command may be ignored: # Preparing profilers: AsyncProfiler # Warmup Iteration 1: [async-profiler] start,event=alloc,interval=1000000 13063.782 ops/s # Warmup Iteration 2: 17541.943 ops/s # Warmup Iteration 3: 18903.507 ops/s Iteration 1: [async-profiler] start,event=alloc,interval=1000000 If I patch AsyncProfiler.java to output the response from the 'start' command, I see: # Preparing profilers: AsyncProfiler # Warmup Iteration 1: [async-profiler] start,event=alloc,interval=1000000 *[async-profiler] Response: Started [alloc] profiling* 13730.857 ops/s # Warmup Iteration 2: 18521.271 ops/s # Warmup Iteration 3: 19195.448 ops/s Iteration 1: [async-profiler] start,event=alloc,interval=1000000 *[async-profiler] Response: Profiler already started* This change seems to solve the problem: diff --git a/jmh-core/src/main/java/org/openjdk/jmh/profile/AsyncProfiler.java b/jmh-core/src/main/java/org/openjdk/jmh/profile/AsyncProfiler.java index e9db5522..09ab53fc 100644 --- a/jmh-core/src/main/java/org/openjdk/jmh/profile/AsyncProfiler.java +++ b/jmh-core/src/main/java/org/openjdk/jmh/profile/AsyncProfiler.java @@ -253,6 +253,9 @@ public final class AsyncProfiler implements ExternalProfiler, InternalProfiler { } } if (iterationParams.getType() == IterationType.MEASUREMENT) { + if (warmupStarted) { + execute("stop"); + } if (!measurementStarted) { // Discard samples collected during warmup and start collecting again. execute("start," + profilerConfig); Mark On Wed, 5 Aug 2020 at 08:28, Aleksey Shipilev wrote: > On 8/5/20 12:14 AM, Jason Zaugg wrote: > > I'm not aware of anything further. It's working for me as a > > replacement for the old integration. > > > > No doubt wider battle testing will throw up some issues; I'll keep an > > eye on this list and address them. > > > > I gave the code a final review pass. Here's what I found that needs a > > final tidy up. > > Ok, pushed. > > -- > -Aleksey > > From duke at openjdk.java.net Mon Oct 5 09:19:51 2020 From: duke at openjdk.java.net (duke) Date: Mon, 5 Oct 2020 09:19:51 GMT Subject: git: openjdk/jmh: Add README.md Message-ID: <87bea2df-ed29-482a-97d9-e2e5dda3a376@openjdk.java.net> Changeset: a2d78d53 Author: Aleksey Shipilev Date: 2020-10-05 11:17:59 +0000 URL: https://git.openjdk.java.net/jmh/commit/a2d78d53 Add README.md + README.md From shade at redhat.com Mon Oct 5 09:22:34 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 5 Oct 2020 11:22:34 +0200 Subject: [ANN] JMH development had been moved to GitHub Message-ID: <309364be-5165-b8d7-0582-d3ae9a6b0444@redhat.com> Hi, This is the organizational announcement. Starting today, JMH development is done at GitHub: https://github.com/openjdk/jmh I have updated README with current guidelines there. -- Thanks, -Aleksey From duke at openjdk.java.net Mon Oct 5 09:22:51 2020 From: duke at openjdk.java.net (duke) Date: Mon, 5 Oct 2020 09:22:51 GMT Subject: git: openjdk/jmh: Update README Message-ID: <94bb8523-8b1b-478c-9a59-a5a49b211335@openjdk.java.net> Changeset: 3e730f8f Author: Aleksey Shipilev Date: 2020-10-05 11:22:24 +0000 URL: https://git.openjdk.java.net/jmh/commit/3e730f8f Update README ! README.md From duke at openjdk.java.net Mon Oct 5 09:26:56 2020 From: duke at openjdk.java.net (duke) Date: Mon, 5 Oct 2020 09:26:56 GMT Subject: git: openjdk/jmh: 2 new changesets Message-ID: <9e2b2387-9163-4910-b422-f9bb75b0a533@openjdk.java.net> Changeset: 1771ae58 Author: Aleksey Shipilev Date: 2020-10-05 11:25:25 +0000 URL: https://git.openjdk.java.net/jmh/commit/1771ae58 Typos in README ! README.md Changeset: 73217f9b Author: Aleksey Shipilev Date: 2020-10-05 11:25:43 +0000 URL: https://git.openjdk.java.net/jmh/commit/73217f9b Temporarily accept changes with only 1 committer review ! .jcheck/conf From shade at redhat.com Mon Oct 5 10:26:36 2020 From: shade at redhat.com (shade at redhat.com) Date: Mon, 05 Oct 2020 10:26:36 +0000 Subject: hg: code-tools/jmh: Provide the warning message for outdated Mercurial repository Message-ID: <202010051026.095AQaTE018419@aojmv0008.oracle.com> Changeset: 2be2df7dbaf8 Author: shade Date: 2020-10-05 12:26 +0200 URL: https://hg.openjdk.java.net/code-tools/jmh/rev/2be2df7dbaf8 Provide the warning message for outdated Mercurial repository + README.md ! jmh-core/src/main/java/org/openjdk/jmh/runner/Runner.java From duke at openjdk.java.net Mon Oct 5 11:12:18 2020 From: duke at openjdk.java.net (duke) Date: Mon, 5 Oct 2020 11:12:18 GMT Subject: git: openjdk/jmh: 7902773: async profiler should discard warmup data properly Message-ID: <28d42847-e2f6-4a10-b711-b5157275e409@openjdk.java.net> Changeset: 2398e8e8 Author: Aleksey Shipilev Date: 2020-10-05 13:10:48 +0000 URL: https://git.openjdk.java.net/jmh/commit/2398e8e8 7902773: async profiler should discard warmup data properly ! jmh-core/src/main/java/org/openjdk/jmh/profile/AsyncProfiler.java From shade at redhat.com Mon Oct 5 11:13:14 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 5 Oct 2020 13:13:14 +0200 Subject: Patch: Integrate async-profiler In-Reply-To: References: <5ab55bb0-9edf-04d7-a2a3-165e1315ecd5@redhat.com> <35d7ceac-c50b-a6cf-5747-d072545ce867@redhat.com> Message-ID: <93d22b99-3bb5-73e1-7455-44a769ad0d25@redhat.com> Hi Mark, On 10/1/20 3:25 PM, Mark Price wrote: > thanks for the work on including async-profiler support. > I'm seeing some samples from warm-up iterations in the generated output, but it looks as though the > intent is to effectively trash the samples from the warm-up phase: Yes. That explains why I saw warmup profiles as well. I had not followed up back then. I think the proper fix is this: https://github.com/openjdk/jmh/commit/2398e8e8b5518ea1229ba254792a4bd9df428ec0 Would you mind checking if it works for you? I works for me. (I intended to push it to Git branch, but oh well). -- Thanks, -Aleksey From duke at openjdk.java.net Mon Oct 5 11:47:50 2020 From: duke at openjdk.java.net (duke) Date: Mon, 5 Oct 2020 11:47:50 GMT Subject: git: openjdk/jmh: Do "mvn install" for snapshot-dependent cases Message-ID: Changeset: 0e7bc7fd Author: Aleksey Shipilev Date: 2020-10-05 13:46:54 +0000 URL: https://git.openjdk.java.net/jmh/commit/0e7bc7fd Do "mvn install" for snapshot-dependent cases ! README.md From mark.web.mail at gmail.com Mon Oct 5 11:56:10 2020 From: mark.web.mail at gmail.com (Mark Price) Date: Mon, 5 Oct 2020 12:56:10 +0100 Subject: Patch: Integrate async-profiler In-Reply-To: <93d22b99-3bb5-73e1-7455-44a769ad0d25@redhat.com> References: <5ab55bb0-9edf-04d7-a2a3-165e1315ecd5@redhat.com> <35d7ceac-c50b-a6cf-5747-d072545ce867@redhat.com> <93d22b99-3bb5-73e1-7455-44a769ad0d25@redhat.com> Message-ID: Good catch! Yes, that seems to work fine. Thanks for checking. Mark On Mon, 5 Oct 2020 at 12:13, Aleksey Shipilev wrote: > Hi Mark, > > On 10/1/20 3:25 PM, Mark Price wrote: > > thanks for the work on including async-profiler support. > > I'm seeing some samples from warm-up iterations in the generated output, > but it looks as though the > > intent is to effectively trash the samples from the warm-up phase: > > Yes. That explains why I saw warmup profiles as well. I had not followed > up back then. > > I think the proper fix is this: > > https://github.com/openjdk/jmh/commit/2398e8e8b5518ea1229ba254792a4bd9df428ec0 > > Would you mind checking if it works for you? I works for me. > > (I intended to push it to Git branch, but oh well). > > -- > Thanks, > -Aleksey > > From duke at openjdk.java.net Wed Oct 7 11:06:06 2020 From: duke at openjdk.java.net (duke) Date: Wed, 7 Oct 2020 11:06:06 GMT Subject: git: openjdk/jmh: 2 new changesets Message-ID: <1f220054-ad63-479a-b41a-908b5ea0d679@openjdk.java.net> Changeset: f21e2285 Author: Aleksey Shipilev Date: 2020-10-07 12:53:12 +0000 URL: https://git.openjdk.java.net/jmh/commit/f21e2285 Experimentally support AuxCounters EVENTs for all benchmark types ! jmh-core-it/src/test/java/org/openjdk/jmh/it/auxcounters/AuxCountersEventsTest.java ! jmh-core/src/main/java/org/openjdk/jmh/generators/core/BenchmarkGenerator.java ! jmh-core/src/main/java/org/openjdk/jmh/generators/core/StateObjectHandler.java Changeset: 82ebaac4 Author: Aleksey Shipilev Date: 2020-10-07 12:53:52 +0000 URL: https://git.openjdk.java.net/jmh/commit/82ebaac4 Stabilize batchsize integration tests by counting the raw ops/time ! jmh-core-it/src/test/java/org/openjdk/jmh/it/batchsize/BatchSizeSanityTest.java ! jmh-core-it/src/test/java/org/openjdk/jmh/it/batchsize/OpsPerInvSanityTest.java From duke at openjdk.java.net Thu Oct 8 13:00:55 2020 From: duke at openjdk.java.net (duke) Date: Thu, 8 Oct 2020 13:00:55 GMT Subject: git: openjdk/jmh: 2 new changesets Message-ID: Changeset: 3b55a591 Author: Aleksey Shipilev Date: 2020-10-08 14:30:01 +0000 URL: https://git.openjdk.java.net/jmh/commit/3b55a591 7902778: JMH separate classpath JAR generation fails when JAR path is not relative to tmpdir ! jmh-core/src/main/java/org/openjdk/jmh/runner/Runner.java Changeset: 90eaa259 Author: Aleksey Shipilev Date: 2020-10-08 14:33:34 +0000 URL: https://git.openjdk.java.net/jmh/commit/90eaa259 7902779: JMH: Security manager enabled tests fail on Windows with "access denied" to lock file ! jmh-core/src/main/resources/jmh-security-minimal-runner.policy From duke at openjdk.java.net Thu Oct 8 13:39:22 2020 From: duke at openjdk.java.net (duke) Date: Thu, 8 Oct 2020 13:39:22 GMT Subject: git: openjdk/jmh: Make batchsize tests more resilient by disabling sync iterations Message-ID: <5735f77b-1789-4b43-9903-b232bb0984da@openjdk.java.net> Changeset: 3923c4e0 Author: Aleksey Shipilev Date: 2020-10-08 15:32:59 +0000 URL: https://git.openjdk.java.net/jmh/commit/3923c4e0 Make batchsize tests more resilient by disabling sync iterations ! jmh-core-it/src/test/java/org/openjdk/jmh/it/batchsize/BatchSizeSanityTest.java ! jmh-core-it/src/test/java/org/openjdk/jmh/it/batchsize/OpsPerInvSanityTest.java From shade at openjdk.java.net Thu Oct 8 15:05:53 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 8 Oct 2020 15:05:53 GMT Subject: RFR: JMH Pre-Integration Tests workflow Message-ID: This adds the basic pre-integration test workflow for the project. ------------- Commit messages: - Disable commit on push - Merge branch 'master' into gh-actions - Merge branch 'master' into gh-actions - Merge branch 'master' into gh-actions - Drop max-parallel from pre-integration workflow - Testing more extensive configuration space - Mention pre-integration workflow in README - Basic pre-integration workflow for JMH Changes: https://git.openjdk.java.net/jmh/pull/5/files Webrev: https://webrevs.openjdk.java.net/?repo=jmh&pr=5&range=00 Stats: 37 lines in 2 files changed: 37 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jmh/pull/5.diff Fetch: git fetch https://git.openjdk.java.net/jmh pull/5/head:pull/5 PR: https://git.openjdk.java.net/jmh/pull/5 From duke at openjdk.java.net Thu Oct 8 15:25:18 2020 From: duke at openjdk.java.net (duke) Date: Thu, 8 Oct 2020 15:25:18 GMT Subject: git: openjdk/jmh: Amend 7902778: fix the test condition Message-ID: <5a90e405-8690-4935-8410-d42a2e1ed058@openjdk.java.net> Changeset: 5808918c Author: Aleksey Shipilev Date: 2020-10-08 17:23:43 +0000 URL: https://git.openjdk.java.net/jmh/commit/5808918c Amend 7902778: fix the test condition ! jmh-core/src/main/java/org/openjdk/jmh/runner/Runner.java From shade at openjdk.java.net Thu Oct 8 15:28:19 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 8 Oct 2020 15:28:19 GMT Subject: RFR: JMH Pre-Integration Tests workflow [v2] In-Reply-To: References: Message-ID: <7ewpW-btugEdv-2pQpmzpprrk-QKpjx1c_xPR2pf1Io=.76853b28-e7c3-4f14-997b-bc2bfcfeddf7@github.com> > This adds the basic pre-integration test workflow for the project. Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: - Merge branch 'master' into gh-actions - Disable commit on push - Merge branch 'master' into gh-actions - Merge branch 'master' into gh-actions - Merge branch 'master' into gh-actions - Drop max-parallel from pre-integration workflow - Testing more extensive configuration space - Mention pre-integration workflow in README - Basic pre-integration workflow for JMH ------------- Changes: - all: https://git.openjdk.java.net/jmh/pull/5/files - new: https://git.openjdk.java.net/jmh/pull/5/files/2ca6af4f..fa39616f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmh&pr=5&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmh&pr=5&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jmh/pull/5.diff Fetch: git fetch https://git.openjdk.java.net/jmh pull/5/head:pull/5 PR: https://git.openjdk.java.net/jmh/pull/5 From shade at openjdk.java.net Thu Oct 8 15:37:32 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 8 Oct 2020 15:37:32 GMT Subject: RFR: JMH Pre-Integration Tests workflow [v3] In-Reply-To: References: Message-ID: > This adds the basic pre-integration test workflow for the project. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Add JDK 7, disable some excessive configurations from testing ------------- Changes: - all: https://git.openjdk.java.net/jmh/pull/5/files - new: https://git.openjdk.java.net/jmh/pull/5/files/fa39616f..80de40e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmh&pr=5&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jmh&pr=5&range=01-02 Stats: 8 lines in 1 file changed: 4 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jmh/pull/5.diff Fetch: git fetch https://git.openjdk.java.net/jmh pull/5/head:pull/5 PR: https://git.openjdk.java.net/jmh/pull/5 From shade at openjdk.java.net Thu Oct 8 15:48:35 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 8 Oct 2020 15:48:35 GMT Subject: RFR: JMH Pre-Integration Tests workflow [v4] In-Reply-To: References: Message-ID: > This adds the basic pre-integration test workflow for the project. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Trying to get non-Linux platforms skip the tests ------------- Changes: - all: https://git.openjdk.java.net/jmh/pull/5/files - new: https://git.openjdk.java.net/jmh/pull/5/files/80de40e6..48848000 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmh&pr=5&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jmh&pr=5&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jmh/pull/5.diff Fetch: git fetch https://git.openjdk.java.net/jmh pull/5/head:pull/5 PR: https://git.openjdk.java.net/jmh/pull/5 From duke at openjdk.java.net Fri Oct 9 08:32:50 2020 From: duke at openjdk.java.net (duke) Date: Fri, 9 Oct 2020 08:32:50 GMT Subject: git: openjdk/jmh: Do not trim stack traces in maven-surefire-plugin runs Message-ID: <2b668a16-fb7c-4ab9-b203-9940d2467414@openjdk.java.net> Changeset: dd8d3ea8 Author: Aleksey Shipilev Date: 2020-10-09 10:32:19 +0000 URL: https://git.openjdk.java.net/jmh/commit/dd8d3ea8 Do not trim stack traces in maven-surefire-plugin runs ! pom.xml From duke at openjdk.java.net Fri Oct 9 09:15:38 2020 From: duke at openjdk.java.net (duke) Date: Fri, 9 Oct 2020 09:15:38 GMT Subject: git: openjdk/jmh: 2 new changesets Message-ID: <84d94e41-aaa3-438f-ada5-f796ab38a2d1@openjdk.java.net> Changeset: ec30ae7f Author: Aleksey Shipilev Date: 2020-10-09 10:58:30 +0000 URL: https://git.openjdk.java.net/jmh/commit/ec30ae7f jmh-core-it: isolate integration tests better, in case they set system properties ! jmh-core-it/pom.xml Changeset: 095c5d45 Author: Aleksey Shipilev Date: 2020-10-09 11:09:52 +0000 URL: https://git.openjdk.java.net/jmh/commit/095c5d45 7902782: JMH separate classpath JAR generation fails when file cannot be read through the relativized path ! jmh-core/src/main/java/org/openjdk/jmh/runner/Runner.java From shade at openjdk.java.net Fri Oct 9 09:18:33 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 9 Oct 2020 09:18:33 GMT Subject: RFR: JMH Pre-Integration Tests workflow [v5] In-Reply-To: References: Message-ID: > This adds the basic pre-integration test workflow for the project. Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge branch 'master' into gh-actions - Trying to get non-Linux platforms skip the tests - Add JDK 7, disable some excessive configurations from testing - Merge branch 'master' into gh-actions - Disable commit on push - Merge branch 'master' into gh-actions - Merge branch 'master' into gh-actions - Merge branch 'master' into gh-actions - Drop max-parallel from pre-integration workflow - Testing more extensive configuration space - ... and 2 more: https://git.openjdk.java.net/jmh/compare/441128ab...d9afcc71 ------------- Changes: - all: https://git.openjdk.java.net/jmh/pull/5/files - new: https://git.openjdk.java.net/jmh/pull/5/files/48848000..d9afcc71 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmh&pr=5&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jmh&pr=5&range=03-04 Stats: 13 lines in 3 files changed: 11 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jmh/pull/5.diff Fetch: git fetch https://git.openjdk.java.net/jmh pull/5/head:pull/5 PR: https://git.openjdk.java.net/jmh/pull/5 From duke at openjdk.java.net Fri Oct 9 10:37:59 2020 From: duke at openjdk.java.net (duke) Date: Fri, 9 Oct 2020 10:37:59 GMT Subject: git: openjdk/jmh: JMH Pre-Integration Tests workflow (#5) Message-ID: <1c326e65-83a8-4935-94b5-0a08b65edfad@openjdk.java.net> Changeset: 896794b3 Author: Aleksey Shipilev Committer: GitHub Date: 2020-10-09 12:37:42 +0000 URL: https://git.openjdk.java.net/jmh/commit/896794b3 JMH Pre-Integration Tests workflow (#5) + .github/workflows/pre-integration.yml ! README.md From shade at openjdk.java.net Fri Oct 9 10:40:20 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 9 Oct 2020 10:40:20 GMT Subject: Withdrawn: JMH Pre-Integration Tests workflow In-Reply-To: References: Message-ID: On Thu, 8 Oct 2020 15:01:50 GMT, Aleksey Shipilev wrote: > This adds the basic pre-integration test workflow for the project. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jmh/pull/5 From shade at redhat.com Fri Oct 9 11:47:11 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 9 Oct 2020 13:47:11 +0200 Subject: JMH 1.26 Message-ID: <2efc7e4d-f2c1-5669-bec8-e115bdaa0c03@redhat.com> Hi, JMH 1.26 is released and available on Maven Central. This fixes a bunch of runner and test bugs that reproduce reliably in GitHub CIs. Additionally, there are two profiler UX fixes for new and old profilers. Important changes include: *) Separate classpath JAR fixes. This affects Windows and Mac OS that can routinely have tmpdirs and current dirs on different device paths: 7902778: JMH separate classpath JAR generation fails when JAR path is not relative to tmpdir Amend 7902778: fix the test condition 7902782: JMH separate classpath JAR generation fails when file cannot be read... *) async profiler fixes: 7902773: async profiler should discard warmup data properly *) perf and perfnorm profiler fixes: 7902769: "perf" and "perfnorm" profilers should consistently report IPC/CPI Enjoy! -- Thanks, -Aleksey From duke at openjdk.java.net Fri Oct 9 11:48:01 2020 From: duke at openjdk.java.net (duke) Date: Fri, 9 Oct 2020 11:48:01 GMT Subject: git: openjdk/jmh: 2 new changesets Message-ID: <6888a5f3-a90a-488c-b62c-c0c7a32fa590@openjdk.java.net> Changeset: 319a92a2 Author: Aleksey Shipilev Date: 2020-10-09 12:56:06 +0000 URL: https://git.openjdk.java.net/jmh/commit/319a92a2 JMH v1.26. ! jmh-archetypes/jmh-groovy-benchmark-archetype/pom.xml ! jmh-archetypes/jmh-java-benchmark-archetype/pom.xml ! jmh-archetypes/jmh-kotlin-benchmark-archetype/pom.xml ! jmh-archetypes/jmh-scala-benchmark-archetype/pom.xml ! jmh-archetypes/pom.xml ! jmh-core-benchmarks/pom.xml ! jmh-core-ct/pom.xml ! jmh-core-it/pom.xml ! jmh-core/pom.xml ! jmh-generator-annprocess/pom.xml ! jmh-generator-asm/pom.xml ! jmh-generator-bytecode/pom.xml ! jmh-generator-reflection/pom.xml ! jmh-samples/pom.xml ! pom.xml Changeset: 352098cd Author: Aleksey Shipilev Date: 2020-10-09 12:56:33 +0000 URL: https://git.openjdk.java.net/jmh/commit/352098cd Continue in 1.27-SNAPSHOT ! jmh-archetypes/jmh-groovy-benchmark-archetype/pom.xml ! jmh-archetypes/jmh-java-benchmark-archetype/pom.xml ! jmh-archetypes/jmh-kotlin-benchmark-archetype/pom.xml ! jmh-archetypes/jmh-scala-benchmark-archetype/pom.xml ! jmh-archetypes/pom.xml ! jmh-core-benchmarks/pom.xml ! jmh-core-ct/pom.xml ! jmh-core-it/pom.xml ! jmh-core/pom.xml ! jmh-generator-annprocess/pom.xml ! jmh-generator-asm/pom.xml ! jmh-generator-bytecode/pom.xml ! jmh-generator-reflection/pom.xml ! jmh-samples/pom.xml ! pom.xml From duke at openjdk.java.net Fri Oct 9 17:01:14 2020 From: duke at openjdk.java.net (duke) Date: Fri, 9 Oct 2020 17:01:14 GMT Subject: git: openjdk/jmh: Remove obsolete .hgignore and .hgtags Message-ID: <08d2851a-8360-4d65-9be8-375f618079c1@openjdk.java.net> Changeset: c15983e8 Author: Aleksey Shipilev Date: 2020-10-09 19:00:16 +0000 URL: https://git.openjdk.java.net/jmh/commit/c15983e8 Remove obsolete .hgignore and .hgtags - .hgignore - .hgtags From duke at openjdk.java.net Tue Oct 13 06:26:43 2020 From: duke at openjdk.java.net (duke) Date: Tue, 13 Oct 2020 06:26:43 GMT Subject: git: openjdk/jmh: Full link to JMH bug tracker Message-ID: <6f4cc94a-e72e-4b34-9a93-1888a48b97ca@openjdk.java.net> Changeset: 007589a3 Author: Aleksey Shipilev Date: 2020-10-13 08:26:01 +0000 URL: https://git.openjdk.java.net/jmh/commit/007589a3 Full link to JMH bug tracker ! README.md From github.com+415502+stokito at openjdk.java.net Wed Oct 21 08:16:21 2020 From: github.com+415502+stokito at openjdk.java.net (Sergey Ponomarev) Date: Wed, 21 Oct 2020 08:16:21 GMT Subject: RFR: Runner: if -Djmh.ignoreLock=true then skip jmh.lock creation Message-ID: When -Djmh.ignoreLock=true JMH anyway will try to create the jmh.lock file and if it fails it will write a warning for an user. This may be not a best way for several reasons: 1. If user specified ignoreLock then he already knows what she or he doing. 2. If the Benchmark is started from IDE i.e idea-jmh-plugin and the ignoreLock was added automatically then users may be confused by this warning 3. It makes execution slightly longer when we anyway trying to create the jmh.lock file 4. This simplifies logic ------------- Commit messages: - Runner: if -Djmh.ignoreLock=true then skip jmh.lock creation Changes: https://git.openjdk.java.net/jmh/pull/6/files Webrev: https://webrevs.openjdk.java.net/?repo=jmh&pr=6&range=00 Stats: 14 lines in 1 file changed: 3 ins; 9 del; 2 mod Patch: https://git.openjdk.java.net/jmh/pull/6.diff Fetch: git fetch https://git.openjdk.java.net/jmh pull/6/head:pull/6 PR: https://git.openjdk.java.net/jmh/pull/6 From shade at openjdk.java.net Wed Oct 21 08:29:36 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 21 Oct 2020 08:29:36 GMT Subject: RFR: Runner: if -Djmh.ignoreLock=true then skip jmh.lock creation In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 08:12:42 GMT, Sergey Ponomarev wrote: > When -Djmh.ignoreLock=true JMH anyway will try to create the jmh.lock file and if it fails it will write a warning for > an user. This may be not a best way for several reasons: > 1. If user specified ignoreLock then he already knows what she or he doing. > 2. If the Benchmark is started from IDE i.e idea-jmh-plugin and the ignoreLock was added automatically then users may > be confused by this warning 3. It makes execution slightly longer when we anyway trying to create the jmh.lock file > 4. This simplifies logic I think avoiding touching the `jmh.lock` file is a good thing, but I don't think we should be silent about explicit lock ignore. jmh-core/src/main/java/org/openjdk/jmh/runner/Runner.java line 206: > 204: if (lock == null) { > 205: String msg = "Unable to acquire the JMH lock (" + JMH_LOCK_FILE + "): already taken by another JMH > instance"; 206: throw new RunnerException("ERROR: " + msg + ", exiting. Use -Djmh.ignoreLock=true to > forcefully continue."); The local `msg` here was to use it in both branches. Since both branches are gone, this could be just: `throw new RunnerException("ERROR: Unable to acquire the JMH lock (" + JMH_LOCK_FILE + "), already taken by another JMH instance, exiting. Use -Djmh.ignoreLock=true to forcefully continue.");` jmh-core/src/main/java/org/openjdk/jmh/runner/Runner.java line 212: > 210: } catch (IOException e) { > 211: String msg = "Exception while trying to acquire the JMH lock (" + JMH_LOCK_FILE + "): " + > e.getMessage(); 212: throw new RunnerException("ERROR: " + msg + ", exiting. Use -Djmh.ignoreLock=true to > forcefully continue."); Similarly, `throw new RunnerException("ERROR: Exception while trying to acquire the JMH lock (" + JMH_LOCK_FILE + "), exiting. Use -Djmh.ignoreLock=true to forcefully continue.", e);` jmh-core/src/main/java/org/openjdk/jmh/runner/Runner.java line 185: > 183: public Collection run() throws RunnerException { > 184: if (JMH_LOCK_IGNORE) { > 185: return internalRun(); We should still print the warning here. `-Djmh.ignoreLock=true` must not go unnoticed, because it has a potential to break performance benchmarks. (I guess it is a separate discussion why does any plugin pass it in -- it should not without user knowing!). So, I suggest: if (JMH_LOCK_IGNORE) { out.println("# WARNING: JMH lock is ignored by user request, make sure no other JMH instances are running"); return internalRun(); } ------------- Changes requested by shade (Committer). PR: https://git.openjdk.java.net/jmh/pull/6 From shade at openjdk.java.net Wed Oct 21 08:29:36 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 21 Oct 2020 08:29:36 GMT Subject: RFR: Runner: if -Djmh.ignoreLock=true then skip jmh.lock creation In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 08:18:29 GMT, Aleksey Shipilev wrote: >> When -Djmh.ignoreLock=true JMH anyway will try to create the jmh.lock file and if it fails it will write a warning for >> an user. This may be not a best way for several reasons: >> 1. If user specified ignoreLock then he already knows what she or he doing. >> 2. If the Benchmark is started from IDE i.e idea-jmh-plugin and the ignoreLock was added automatically then users may >> be confused by this warning 3. It makes execution slightly longer when we anyway trying to create the jmh.lock file >> 4. This simplifies logic > > jmh-core/src/main/java/org/openjdk/jmh/runner/Runner.java line 212: > >> 210: } catch (IOException e) { >> 211: String msg = "Exception while trying to acquire the JMH lock (" + JMH_LOCK_FILE + "): " + >> e.getMessage(); 212: throw new RunnerException("ERROR: " + msg + ", exiting. Use -Djmh.ignoreLock=true to >> forcefully continue."); > > Similarly, `throw new RunnerException("ERROR: Exception while trying to acquire the JMH lock (" + JMH_LOCK_FILE + "), > exiting. Use -Djmh.ignoreLock=true to forcefully continue.", e);` Note the change above also links in the `IOException` as the cause. ------------- PR: https://git.openjdk.java.net/jmh/pull/6 From github.com+415502+stokito at openjdk.java.net Wed Oct 21 08:47:28 2020 From: github.com+415502+stokito at openjdk.java.net (Sergey Ponomarev) Date: Wed, 21 Oct 2020 08:47:28 GMT Subject: RFR: Runner: if -Djmh.ignoreLock=true then skip jmh.lock creation [v2] In-Reply-To: References: Message-ID: > When -Djmh.ignoreLock=true JMH anyway will try to create the jmh.lock file and if it fails it will write a warning for an user. > This may be not a best way for several reasons: > 1. If user specified ignoreLock then he already knows what she or he doing. > 2. If the Benchmark is started from IDE i.e idea-jmh-plugin and the ignoreLock was added automatically then users may be confused by this warning > 3. It makes execution slightly longer when we anyway trying to create the jmh.lock file > 4. This simplifies logic Sergey Ponomarev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Runner: if -Djmh.ignoreLock=true then skip jmh.lock creation Signed-off-by: Sergey Ponomarev ------------- Changes: - all: https://git.openjdk.java.net/jmh/pull/6/files - new: https://git.openjdk.java.net/jmh/pull/6/files/f5986702..cdb9fbc2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmh&pr=6&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmh&pr=6&range=00-01 Stats: 5 lines in 1 file changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jmh/pull/6.diff Fetch: git fetch https://git.openjdk.java.net/jmh pull/6/head:pull/6 PR: https://git.openjdk.java.net/jmh/pull/6 From shade at openjdk.java.net Wed Oct 21 08:51:55 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 21 Oct 2020 08:51:55 GMT Subject: RFR: Runner: if -Djmh.ignoreLock=true then skip jmh.lock creation [v2] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 08:47:28 GMT, Sergey Ponomarev wrote: >> When -Djmh.ignoreLock=true JMH anyway will try to create the jmh.lock file and if it fails it will write a warning for an user. >> This may be not a best way for several reasons: >> 1. If user specified ignoreLock then he already knows what she or he doing. >> 2. If the Benchmark is started from IDE i.e idea-jmh-plugin and the ignoreLock was added automatically then users may be confused by this warning >> 3. It makes execution slightly longer when we anyway trying to create the jmh.lock file >> 4. This simplifies logic > > Sergey Ponomarev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Runner: if -Djmh.ignoreLock=true then skip jmh.lock creation > > Signed-off-by: Sergey Ponomarev Marked as reviewed by shade (Committer). ------------- PR: https://git.openjdk.java.net/jmh/pull/6 From github.com+415502+stokito at openjdk.java.net Wed Oct 21 09:03:00 2020 From: github.com+415502+stokito at openjdk.java.net (Sergey Ponomarev) Date: Wed, 21 Oct 2020 09:03:00 GMT Subject: RFR: Runner: if -Djmh.ignoreLock=true then skip jmh.lock creation [v2] In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 08:49:21 GMT, Aleksey Shipilev wrote: >> Sergey Ponomarev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> Runner: if -Djmh.ignoreLock=true then skip jmh.lock creation >> >> Signed-off-by: Sergey Ponomarev > > Marked as reviewed by shade (Committer). BTW: for me usage of the system variable here looks as not a best choice: it may be better to use command line options and put the flag it into `Options` class. If in future this code will be refactored this may be a thing to think about. Thank you for accepting the PR. ------------- PR: https://git.openjdk.java.net/jmh/pull/6 From github.com+415502+stokito at openjdk.java.net Wed Oct 21 09:11:57 2020 From: github.com+415502+stokito at openjdk.java.net (Sergey Ponomarev) Date: Wed, 21 Oct 2020 09:11:57 GMT Subject: Integrated: Runner: if -Djmh.ignoreLock=true then skip jmh.lock creation In-Reply-To: References: Message-ID: On Wed, 21 Oct 2020 08:12:42 GMT, Sergey Ponomarev wrote: > When -Djmh.ignoreLock=true JMH anyway will try to create the jmh.lock file and if it fails it will write a warning for an user. > This may be not a best way for several reasons: > 1. If user specified ignoreLock then he already knows what she or he doing. > 2. If the Benchmark is started from IDE i.e idea-jmh-plugin and the ignoreLock was added automatically then users may be confused by this warning > 3. It makes execution slightly longer when we anyway trying to create the jmh.lock file > 4. This simplifies logic This pull request has now been integrated. Changeset: 57bb8c87 Author: Sergey Ponomarev Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jmh/commit/57bb8c87 Stats: 17 lines in 1 file changed: 4 ins; 11 del; 2 mod Runner: if -Djmh.ignoreLock=true then skip jmh.lock creation Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jmh/pull/6 From github.com+415502+stokito at openjdk.java.net Thu Oct 22 10:27:20 2020 From: github.com+415502+stokito at openjdk.java.net (Sergey Ponomarev) Date: Thu, 22 Oct 2020 10:27:20 GMT Subject: RFR: StateObjectHandler.validateState(): fix typo and optimize Message-ID: Last commit contains extract of two methods from duplicated code that IntelliJ found. Not sure if this change has any value for you so I can revert it ------------- Commit messages: - StateObjectHandler.validateState(): extract methods from duplicated lines - StateObjectHandler.validateState(): early break for default constructor - StateObjectHandler.validateState(): fix typo Changes: https://git.openjdk.java.net/jmh/pull/7/files Webrev: https://webrevs.openjdk.java.net/?repo=jmh&pr=7&range=00 Stats: 77 lines in 1 file changed: 29 ins; 41 del; 7 mod Patch: https://git.openjdk.java.net/jmh/pull/7.diff Fetch: git fetch https://git.openjdk.java.net/jmh pull/7/head:pull/7 PR: https://git.openjdk.java.net/jmh/pull/7 From shade at openjdk.java.net Thu Oct 22 13:55:14 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 22 Oct 2020 13:55:14 GMT Subject: RFR: StateObjectHandler.validateState(): fix typo and optimize In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 10:22:17 GMT, Sergey Ponomarev wrote: > Last commit contains extract of two methods from duplicated code that IntelliJ found. Not sure if this change has any value for you so I can revert it It might be a good cleanup. However, the style is usually to return `Collection`, and then do e.g.: for (String s : addStateInitializersParamsLabels(so)) writer.println(ident(1) + s); ...and remove the indents from the helper methods. That way we can make sure indenting in the generated code is fine. (You might want to check it with your own eyes anyway). jmh-core/src/main/java/org/openjdk/jmh/generators/core/StateObjectHandler.java line 780: > 778: } > 779: } > 780: addStateInitializersHelpers(result, so); Shouldn't the block above also be replaced with `addStateInitializersParamsLabels`? ------------- Changes requested by shade (Committer). PR: https://git.openjdk.java.net/jmh/pull/7 From github.com+415502+stokito at openjdk.java.net Sat Oct 24 16:21:46 2020 From: github.com+415502+stokito at openjdk.java.net (Sergey Ponomarev) Date: Sat, 24 Oct 2020 16:21:46 GMT Subject: RFR: StateObjectHandler.validateState(): fix typo and optimize [v2] In-Reply-To: References: Message-ID: > Last commit contains extract of two methods from duplicated code that IntelliJ found. Not sure if this change has any value for you so I can revert it Sergey Ponomarev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. ------------- Changes: - all: https://git.openjdk.java.net/jmh/pull/7/files - new: https://git.openjdk.java.net/jmh/pull/7/files/d217a6ee..1c15c5a3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmh&pr=7&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmh&pr=7&range=00-01 Stats: 72 lines in 1 file changed: 41 ins; 26 del; 5 mod Patch: https://git.openjdk.java.net/jmh/pull/7.diff Fetch: git fetch https://git.openjdk.java.net/jmh pull/7/head:pull/7 PR: https://git.openjdk.java.net/jmh/pull/7 From github.com+415502+stokito at openjdk.java.net Sat Oct 24 16:21:47 2020 From: github.com+415502+stokito at openjdk.java.net (Sergey Ponomarev) Date: Sat, 24 Oct 2020 16:21:47 GMT Subject: RFR: StateObjectHandler.validateState(): fix typo and optimize [v2] In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 13:52:17 GMT, Aleksey Shipilev wrote: >> Sergey Ponomarev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > It might be a good cleanup. However, the style is usually to return `Collection`, and then do e.g.: > > for (String s : addStateInitializersParamsLabels(so)) writer.println(ident(1) + s); > > ...and remove the indents from the helper methods. That way we can make sure indenting in the generated code is fine. (You might want to check it with your own eyes anyway). I just canceled the last commit because it doesn't have a big value but I'm afraid to change logic uncovered by tests > jmh-core/src/main/java/org/openjdk/jmh/generators/core/StateObjectHandler.java line 780: > >> 778: } >> 779: } >> 780: addStateInitializersHelpers(result, so); > > Shouldn't the block above also be replaced with `addStateInitializersParamsLabels`? Actually there is a lot of duplicated lines across the `generators.core` package but in the same time there is almost no tests. I decided not to touch this code at all. So I rolled back the commit. It will be very easy to find such duplicates with IntelliJ so nothing really valuable there. ------------- PR: https://git.openjdk.java.net/jmh/pull/7 From qwwdfsad at gmail.com Mon Oct 26 08:50:55 2020 From: qwwdfsad at gmail.com (Vsevolod Tolstopyatov) Date: Mon, 26 Oct 2020 11:50:55 +0300 Subject: Support Java numeric literals in @Params parameters Message-ID: Hi, During various work with JMH, I've noticed the recurring error pattern in my benchmarks: I'm frequently using underscores in numeric literals in my code, but as soon as I move them to @Params annotation, JMH pre-processor reports an error during the build. E.g. I can write ``` @Param({"100", "1000", "10000"}) int integerParam = 10_000 ``` but not ``` @Param({"100", "1000", "10_000"}) int integerParam = 10_000 ``` It feels inconsistent and also complicates eye-balling parameters, especially when they are the power of 10. It would be nice to support underscores (generally speaking, to support integer literals in the same way javac does) and I am willing to contribute it, but first I would like to ask whether such change is aligned with JMH API shape and is a reasonable addition to JMH at all. -- Best regards, Tolstopyatov Vsevolod From shade at openjdk.java.net Mon Oct 26 08:55:39 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 26 Oct 2020 08:55:39 GMT Subject: RFR: StateObjectHandler.validateState(): fix typo and optimize [v2] In-Reply-To: References: Message-ID: On Sat, 24 Oct 2020 16:21:46 GMT, Sergey Ponomarev wrote: >> Last commit contains extract of two methods from duplicated code that IntelliJ found. Not sure if this change has any value for you so I can revert it > > Sergey Ponomarev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. Marked as reviewed by shade (Committer). ------------- PR: https://git.openjdk.java.net/jmh/pull/7 From github.com+415502+stokito at openjdk.java.net Mon Oct 26 09:01:39 2020 From: github.com+415502+stokito at openjdk.java.net (Sergey Ponomarev) Date: Mon, 26 Oct 2020 09:01:39 GMT Subject: Integrated: StateObjectHandler.validateState(): fix typo and optimize In-Reply-To: References: Message-ID: On Thu, 22 Oct 2020 10:22:17 GMT, Sergey Ponomarev wrote: > Last commit contains extract of two methods from duplicated code that IntelliJ found. Not sure if this change has any value for you so I can revert it This pull request has now been integrated. Changeset: 620036ec Author: Sergey Ponomarev Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jmh/commit/620036ec Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod StateObjectHandler.validateState(): fix typo and optimize Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jmh/pull/7 From github.com+4886855+wangpeipei90 at openjdk.java.net Mon Oct 26 15:04:17 2020 From: github.com+4886855+wangpeipei90 at openjdk.java.net (wangpeipei90) Date: Mon, 26 Oct 2020 15:04:17 GMT Subject: RFR: StateObjectHandler.validateState(): fix typo and optimize [v2] In-Reply-To: References: Message-ID: On Sat, 24 Oct 2020 16:21:46 GMT, Sergey Ponomarev wrote: >> Last commit contains extract of two methods from duplicated code that IntelliJ found. Not sure if this change has any value for you so I can revert it > > Sergey Ponomarev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. jmh-core/src/main/java/org/openjdk/jmh/generators/core/StateObjectHandler.java line 107: > 105: boolean hasDefaultConstructor = false; > 106: for (MethodInfo constructor : state.getConstructors()) { > 107: if (constructor.getParameters().isEmpty()) { The changes here are not equivalent. If any constructor`isEmpty `and `isPublic`, `hasDefaultConstructor` will always be `True`. But in the code change, the early exit could cause `hasDefaultConstructor` be `false` if there is a constructor `isEmpty` but not `isPublic` without iterating the default constructor yet. ------------- PR: https://git.openjdk.java.net/jmh/pull/7 From github.com+415502+stokito at openjdk.java.net Mon Oct 26 15:09:13 2020 From: github.com+415502+stokito at openjdk.java.net (Sergey Ponomarev) Date: Mon, 26 Oct 2020 15:09:13 GMT Subject: RFR: StateObjectHandler.validateState(): fix typo and optimize [v2] In-Reply-To: References: Message-ID: On Mon, 26 Oct 2020 15:02:03 GMT, wangpeipei90 wrote: >> Sergey Ponomarev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > jmh-core/src/main/java/org/openjdk/jmh/generators/core/StateObjectHandler.java line 107: > >> 105: boolean hasDefaultConstructor = false; >> 106: for (MethodInfo constructor : state.getConstructors()) { >> 107: if (constructor.getParameters().isEmpty()) { > > The changes here are not equivalent. If any constructor`isEmpty `and `isPublic`, `hasDefaultConstructor` will always be `True`. > > But in the code change, the early exit could cause `hasDefaultConstructor` be `false` if there is a constructor `isEmpty` but not `isPublic` without iterating the default constructor yet. is it possible to have two default constructors with empty params? Maybe not in Java but in some alternative language? As far I know this is prohibited. If we can have only one empty param constructor then we can check only it for having a public modifier and then skip others ------------- PR: https://git.openjdk.java.net/jmh/pull/7 From github.com+4886855+wangpeipei90 at openjdk.java.net Mon Oct 26 15:25:19 2020 From: github.com+4886855+wangpeipei90 at openjdk.java.net (wangpeipei90) Date: Mon, 26 Oct 2020 15:25:19 GMT Subject: RFR: StateObjectHandler.validateState(): fix typo and optimize [v2] In-Reply-To: References: Message-ID: On Mon, 26 Oct 2020 15:06:18 GMT, Sergey Ponomarev wrote: >> jmh-core/src/main/java/org/openjdk/jmh/generators/core/StateObjectHandler.java line 107: >> >>> 105: boolean hasDefaultConstructor = false; >>> 106: for (MethodInfo constructor : state.getConstructors()) { >>> 107: if (constructor.getParameters().isEmpty()) { >> >> The changes here are not equivalent. If any constructor`isEmpty `and `isPublic`, `hasDefaultConstructor` will always be `True`. >> >> But in the code change, the early exit could cause `hasDefaultConstructor` be `false` if there is a constructor `isEmpty` but not `isPublic` without iterating the default constructor yet. > > is it possible to have two default constructors with empty params? Maybe not in Java but in some alternative language? > As far I know this is prohibited. > If we can have only one empty param constructor then we can check only it for having a public modifier and then skip others I was thinking of the case the default constructor is declared explicitly with the `private` modifier. But you are right that a Java class could not have two default constructors with empty params, according to the rule of the method signature. The change is not equivalent, it still fulfills the same purpose. ------------- PR: https://git.openjdk.java.net/jmh/pull/7 From github.com+415502+stokito at openjdk.java.net Mon Oct 26 15:31:21 2020 From: github.com+415502+stokito at openjdk.java.net (Sergey Ponomarev) Date: Mon, 26 Oct 2020 15:31:21 GMT Subject: RFR: StateObjectHandler.validateState(): fix typo and optimize [v2] In-Reply-To: References: Message-ID: <0VZfJjnyMpUc0vw_WOitGT7xdl9vkGC3DGbsvT6_P1Y=.c1b18718-5f71-4c08-9731-9036485592e1@github.com> On Mon, 26 Oct 2020 15:22:56 GMT, wangpeipei90 wrote: >> is it possible to have two default constructors with empty params? Maybe not in Java but in some alternative language? >> As far I know this is prohibited. >> If we can have only one empty param constructor then we can check only it for having a public modifier and then skip others > > I was thinking of the case the default constructor is declared explicitly with the `private` modifier. But you are right that a Java class could not have two default constructors with empty params, according to the rule of the method signature. The change is not equivalent, it still fulfills the same purpose. ok, so if we are fine here then I'll mark the comment as resolved ------------- PR: https://git.openjdk.java.net/jmh/pull/7 From shade at redhat.com Mon Oct 26 18:06:09 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 26 Oct 2020 19:06:09 +0100 Subject: Support Java numeric literals in @Params parameters In-Reply-To: References: Message-ID: <27ccfbd7-c3a8-8a3c-fb56-5f877327104a@redhat.com> Hi, On 10/26/20 9:50 AM, Vsevolod Tolstopyatov wrote: > ``` > @Param({"100", "1000", "10_000"}) > int integerParam = 10_000 > ``` As the workaround, you can write: @Param({"" + 100, "" + 1_000, "" + 10_000}) int integerParam = 10_000 I understand this is ugly. > It feels inconsistent and also complicates eye-balling parameters, > especially when they are the power of 10. > It would be nice to support underscores (generally speaking, to support > integer literals in the same way javac does) and I am willing to contribute > it, but first I would like to ask whether such change is aligned with JMH > API shape and is a reasonable addition to JMH at all. Well, I remember discussions (or maybe even the patches) about doing this. When JMH still supported JDK 6, supporting underscores was at odds with source/target=6. It does not seem to be an issue anymore: the minimal target is 7, so underscored literals are already there. You can draft up a PR, and we shall see if there are blank spots. -- Thanks, -Aleksey