From shade at openjdk.java.net  Mon Aug  2 06:38:45 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 2 Aug 2021 06:38:45 GMT
Subject: Integrated: CODETOOLS-7903001: JMH: The interrupt to time-outing
 benchmark can be delivered to warmdown latches
In-Reply-To: <MhY939swFV-3-QswlTvBMkA-fjAYvJa4JoNZCxSWXns=.3d831c59-0239-4ead-9f5a-6ef00d453078@github.com>
References: <MhY939swFV-3-QswlTvBMkA-fjAYvJa4JoNZCxSWXns=.3d831c59-0239-4ead-9f5a-6ef00d453078@github.com>
Message-ID: <48azXGCKwwi9EYwlK-lJoXEYCQVJrLg8YOIJfHxkpng=.0e1b1444-033c-4e1b-8f13-309932b14a9b@github.com>

On Fri, 30 Jul 2021 07:02:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug report for details.

This pull request has now been integrated.

Changeset: 3f720717
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jmh/commit/3f720717ab6837d75d0df041d8b1afbaac903960
Stats:     168 lines in 4 files changed: 152 ins; 3 del; 13 mod

7903001: JMH: The interrupt to time-outing benchmark can be delivered to warmdown latches

Reviewed-by: ecaspole

-------------

PR: https://git.openjdk.java.net/jmh/pull/45

From shade at redhat.com  Mon Aug  2 06:52:11 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 2 Aug 2021 09:52:11 +0300
Subject: [External] : Re: InterruptedException in InfraControl.preTearDown
 so far only on ARM
In-Reply-To: <a65f5e20-b980-7b64-0489-16a48b1859b0@oracle.com>
References: <dbe56440-42e5-1775-f3b1-084af0266dd1@oracle.com>
 <02328449-db8a-306f-07e9-fb10b67ef095@redhat.com>
 <a65f5e20-b980-7b64-0489-16a48b1859b0@oracle.com>
Message-ID: <3031cae8-e2cf-cb62-abd8-0865a1e0d0dd@redhat.com>

On 7/30/21 10:55 PM, eric.caspole at oracle.com wrote:
> I tried this patch about 30 times, it always worked and reported the
> score. There is the funny quirk that sometimes there are hundreds (and
> hundreds) of
> (*interrupt*) messages at the end of the iteration before the score is
> printed like below.

Yes, we can help that too:
   https://github.com/openjdk/jmh/pull/47

-- 
Thanks,
-Aleksey


From shade at openjdk.java.net  Mon Aug  2 06:56:59 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 2 Aug 2021 06:56:59 GMT
Subject: RFR: CODETOOLS-7903003: JMH: Print a single interruption message per
 iteration
Message-ID: <PQ4BW_PckZ_MgmCcW34vrEtJRsNxUP05Bc1xHcH77JQ=.9ad59b41-1354-4bdc-8c0c-642428dbdb78@github.com>

When harness interrupts the benchmark, it delivers several interrupts until the benchmark exits. Every time on interrupt, it will print a message, which can flood the logs. We are better printing the interrupt message one time.

-------------

Commit messages:
 - CODETOOLS-7903003: JMH: Print a single interruption message per iteration

Changes: https://git.openjdk.java.net/jmh/pull/47/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jmh&pr=47&range=00
  Issue: https://bugs.openjdk.java.net/browse/CODETOOLS-7903003
  Stats: 7 lines in 1 file changed: 6 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jmh/pull/47.diff
  Fetch: git fetch https://git.openjdk.java.net/jmh pull/47/head:pull/47

PR: https://git.openjdk.java.net/jmh/pull/47

From shade at openjdk.java.net  Mon Aug  2 08:43:55 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 2 Aug 2021 08:43:55 GMT
Subject: RFR: CODETOOLS-7903004: JMH: Compiler Blackholes auto-detection
Message-ID: <XA05TxDu8l_ALOe5DGrPB9zowUEuL_wyXafpUPjm2gs=.4f39a29e-8d67-41fd-9f3f-bde4ab837062@github.com>

This is another step towards better compiler blackholes support. This time, we can enable JMH to auto-detect the support and enable it, if JVM supports it.

-------------

Commit messages:
 - CODETOOLS-7903004: JMH: Compiler Blackholes auto-detection

Changes: https://git.openjdk.java.net/jmh/pull/48/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jmh&pr=48&range=00
  Issue: https://bugs.openjdk.java.net/browse/CODETOOLS-7903004
  Stats: 79 lines in 1 file changed: 73 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jmh/pull/48.diff
  Fetch: git fetch https://git.openjdk.java.net/jmh pull/48/head:pull/48

PR: https://git.openjdk.java.net/jmh/pull/48

From shade at openjdk.java.net  Mon Aug  2 11:00:20 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 2 Aug 2021 11:00:20 GMT
Subject: RFR: CODETOOLS-7903004: JMH: Compiler Blackholes auto-detection
 [v2]
In-Reply-To: <XA05TxDu8l_ALOe5DGrPB9zowUEuL_wyXafpUPjm2gs=.4f39a29e-8d67-41fd-9f3f-bde4ab837062@github.com>
References: <XA05TxDu8l_ALOe5DGrPB9zowUEuL_wyXafpUPjm2gs=.4f39a29e-8d67-41fd-9f3f-bde4ab837062@github.com>
Message-ID: <lo_rLI9pCHUqYn7gPRNlBVLYsPIDeKTeiHDI4awSWl8=.bd5a5988-b5d0-43af-a9bc-fe7c93425639@github.com>

> This is another step towards better compiler blackholes support. This time, we can enable JMH to auto-detect the support and enable it, if JVM supports it.

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  New flag to disable auto-detection

-------------

Changes:
  - all: https://git.openjdk.java.net/jmh/pull/48/files
  - new: https://git.openjdk.java.net/jmh/pull/48/files/1d6c5018..920aa051

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jmh&pr=48&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jmh&pr=48&range=00-01

  Stats: 26 lines in 1 file changed: 13 ins; 6 del; 7 mod
  Patch: https://git.openjdk.java.net/jmh/pull/48.diff
  Fetch: git fetch https://git.openjdk.java.net/jmh pull/48/head:pull/48

PR: https://git.openjdk.java.net/jmh/pull/48

From shade at openjdk.java.net  Mon Aug  2 11:12:09 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 2 Aug 2021 11:12:09 GMT
Subject: RFR: CODETOOLS-7903004: JMH: Compiler Blackholes auto-detection
 [v3]
In-Reply-To: <XA05TxDu8l_ALOe5DGrPB9zowUEuL_wyXafpUPjm2gs=.4f39a29e-8d67-41fd-9f3f-bde4ab837062@github.com>
References: <XA05TxDu8l_ALOe5DGrPB9zowUEuL_wyXafpUPjm2gs=.4f39a29e-8d67-41fd-9f3f-bde4ab837062@github.com>
Message-ID: <lzsZkVcmFDAkM7v89pWub9-S-q4OLJwm1Gw7m6Q_qqU=.2e3c0460-dc5a-404f-ae5b-c27b07bf427f@github.com>

> This is another step towards better compiler blackholes support. This time, we can enable JMH to auto-detect the support and enable it, if JVM supports it.

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Disallow selecting compiler blackholes when they are not available

-------------

Changes:
  - all: https://git.openjdk.java.net/jmh/pull/48/files
  - new: https://git.openjdk.java.net/jmh/pull/48/files/920aa051..f27e2a06

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jmh&pr=48&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jmh&pr=48&range=01-02

  Stats: 11 lines in 1 file changed: 9 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jmh/pull/48.diff
  Fetch: git fetch https://git.openjdk.java.net/jmh pull/48/head:pull/48

PR: https://git.openjdk.java.net/jmh/pull/48

From ecaspole at openjdk.java.net  Mon Aug  2 16:00:50 2021
From: ecaspole at openjdk.java.net (Eric Caspole)
Date: Mon, 2 Aug 2021 16:00:50 GMT
Subject: RFR: CODETOOLS-7903003: JMH: Print a single interruption message
 per iteration
In-Reply-To: <PQ4BW_PckZ_MgmCcW34vrEtJRsNxUP05Bc1xHcH77JQ=.9ad59b41-1354-4bdc-8c0c-642428dbdb78@github.com>
References: <PQ4BW_PckZ_MgmCcW34vrEtJRsNxUP05Bc1xHcH77JQ=.9ad59b41-1354-4bdc-8c0c-642428dbdb78@github.com>
Message-ID: <Svugja1xf2SDh110bP6aTGV1Upy4F4rPZsUDuP_M1oI=.3efa29cf-e61e-43fd-bf53-cefe0a3baa5f@github.com>

On Mon, 2 Aug 2021 06:52:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> When harness interrupts the benchmark, it delivers several interrupts until the benchmark exits. Every time on interrupt, it will print a message, which can flood the logs. We are better printing the interrupt message one time.

This change worked in my case, thanks!

-------------

Marked as reviewed by ecaspole (Committer).

PR: https://git.openjdk.java.net/jmh/pull/47

From shade at openjdk.java.net  Mon Aug  2 16:08:43 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 2 Aug 2021 16:08:43 GMT
Subject: Integrated: CODETOOLS-7903003: JMH: Print a single interruption
 message per iteration
In-Reply-To: <PQ4BW_PckZ_MgmCcW34vrEtJRsNxUP05Bc1xHcH77JQ=.9ad59b41-1354-4bdc-8c0c-642428dbdb78@github.com>
References: <PQ4BW_PckZ_MgmCcW34vrEtJRsNxUP05Bc1xHcH77JQ=.9ad59b41-1354-4bdc-8c0c-642428dbdb78@github.com>
Message-ID: <2ATUHIcm_1nvEj4iodhHwUpJq7dYTfF0BWtyre5gnvA=.d5131cd3-cdd9-4ff1-87fa-7e3f7fc1483b@github.com>

On Mon, 2 Aug 2021 06:52:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> When harness interrupts the benchmark, it delivers several interrupts until the benchmark exits. Every time on interrupt, it will print a message, which can flood the logs. We are better printing the interrupt message one time.

This pull request has now been integrated.

Changeset: dd6e9636
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jmh/commit/dd6e9636173ab7512031132c5ff74eb4d428e884
Stats:     7 lines in 1 file changed: 6 ins; 1 del; 0 mod

7903003: JMH: Print a single interruption message per iteration

Reviewed-by: ecaspole

-------------

PR: https://git.openjdk.java.net/jmh/pull/47

From shade at openjdk.java.net  Tue Aug  3 13:20:08 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 3 Aug 2021 13:20:08 GMT
Subject: RFR: CODETOOLS-7903004: JMH: Compiler Blackholes auto-detection
 [v4]
In-Reply-To: <XA05TxDu8l_ALOe5DGrPB9zowUEuL_wyXafpUPjm2gs=.4f39a29e-8d67-41fd-9f3f-bde4ab837062@github.com>
References: <XA05TxDu8l_ALOe5DGrPB9zowUEuL_wyXafpUPjm2gs=.4f39a29e-8d67-41fd-9f3f-bde4ab837062@github.com>
Message-ID: <86GSmvdRNytf7tSuOGsNHfTVZS7vRSdCDjfKVO3wSss=.4d953a83-a871-456e-b6a2-090fcc760e1a@github.com>

> This is another step towards better [compiler blackholes](https://shipilev.net/jvm/anatomy-quarks/27-compiler-blackholes/) support. This time, we can enable JMH to auto-detect the support and enable it, if JVM supports it. 
> 
> The upside is that users would have much more fidelity in benchmarks and would be be exposed to eventual default Blackhole mode early.
> 
> The flip side is that JDK 17+ benchmarks would suddenly become faster without any user prompt, and maybe run into higher risk for VM bugs in the new blackhole code. I have ran the entire JDK microbenchmark corpus without problems, however, so that possibility should be low.

Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:

 - Auto-detect should be on by default
 - Add another blurb about compiler blackholes at the end of the run

-------------

Changes:
  - all: https://git.openjdk.java.net/jmh/pull/48/files
  - new: https://git.openjdk.java.net/jmh/pull/48/files/f27e2a06..6fbd2aae

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jmh&pr=48&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jmh&pr=48&range=02-03

  Stats: 15 lines in 2 files changed: 14 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jmh/pull/48.diff
  Fetch: git fetch https://git.openjdk.java.net/jmh pull/48/head:pull/48

PR: https://git.openjdk.java.net/jmh/pull/48

From shade at openjdk.java.net  Tue Aug  3 15:01:10 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 3 Aug 2021 15:01:10 GMT
Subject: RFR: CODETOOLS-7903004: JMH: Compiler Blackholes auto-detection
 [v5]
In-Reply-To: <XA05TxDu8l_ALOe5DGrPB9zowUEuL_wyXafpUPjm2gs=.4f39a29e-8d67-41fd-9f3f-bde4ab837062@github.com>
References: <XA05TxDu8l_ALOe5DGrPB9zowUEuL_wyXafpUPjm2gs=.4f39a29e-8d67-41fd-9f3f-bde4ab837062@github.com>
Message-ID: <UZKjA5aPsByCuB2Dofq2myJQh-_aYqBLw6Tj2FytMgI=.9a8eb5cb-e45e-4df3-b174-21d647102311@github.com>

> This is another step towards better [compiler blackholes](https://shipilev.net/jvm/anatomy-quarks/27-compiler-blackholes/) support. This time, we can enable JMH to auto-detect the support and enable it, if JVM supports it. 
> 
> The upside is that users would have much more fidelity in benchmarks and would be be exposed to eventual default Blackhole mode early.
> 
> The flip side is that JDK 17+ benchmarks would suddenly become faster without any user prompt, and maybe run into higher risk for VM bugs in the new blackhole code. I have ran the entire JDK microbenchmark corpus without problems, however, so that possibility should be low.

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Debug logs

-------------

Changes:
  - all: https://git.openjdk.java.net/jmh/pull/48/files
  - new: https://git.openjdk.java.net/jmh/pull/48/files/6fbd2aae..aa7ac278

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jmh&pr=48&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jmh&pr=48&range=03-04

  Stats: 43 lines in 1 file changed: 23 ins; 1 del; 19 mod
  Patch: https://git.openjdk.java.net/jmh/pull/48.diff
  Fetch: git fetch https://git.openjdk.java.net/jmh pull/48/head:pull/48

PR: https://git.openjdk.java.net/jmh/pull/48

From shade at openjdk.java.net  Wed Aug  4 09:05:08 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 4 Aug 2021 09:05:08 GMT
Subject: RFR: CODETOOLS-7903004: JMH: Compiler Blackholes auto-detection
 [v6]
In-Reply-To: <XA05TxDu8l_ALOe5DGrPB9zowUEuL_wyXafpUPjm2gs=.4f39a29e-8d67-41fd-9f3f-bde4ab837062@github.com>
References: <XA05TxDu8l_ALOe5DGrPB9zowUEuL_wyXafpUPjm2gs=.4f39a29e-8d67-41fd-9f3f-bde4ab837062@github.com>
Message-ID: <DsQsaY-IIPTDayxE64vupVagj4qJZps6zfS_QWoXI1I=.a22e1037-0b02-455c-afd7-e2155984209b@github.com>

> This is another step towards better [compiler blackholes](https://shipilev.net/jvm/anatomy-quarks/27-compiler-blackholes/) support. This time, we can enable JMH to auto-detect the support and enable it, if JVM supports it. 
> 
> The upside is that users would have much more fidelity in benchmarks and would be be exposed to eventual default Blackhole mode early.
> 
> The flip side is that JDK 17+ benchmarks would suddenly become faster without any user prompt, and maybe run into higher risk for VM bugs in the new blackhole code. I have ran the entire JDK microbenchmark corpus without problems, however, so that possibility should be low.

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Minor touchups

-------------

Changes:
  - all: https://git.openjdk.java.net/jmh/pull/48/files
  - new: https://git.openjdk.java.net/jmh/pull/48/files/aa7ac278..40542021

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jmh&pr=48&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jmh&pr=48&range=04-05

  Stats: 14 lines in 2 files changed: 6 ins; 6 del; 2 mod
  Patch: https://git.openjdk.java.net/jmh/pull/48.diff
  Fetch: git fetch https://git.openjdk.java.net/jmh pull/48/head:pull/48

PR: https://git.openjdk.java.net/jmh/pull/48

From redestad at openjdk.java.net  Wed Aug  4 09:12:46 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 4 Aug 2021 09:12:46 GMT
Subject: RFR: CODETOOLS-7903004: JMH: Compiler Blackholes auto-detection
 [v6]
In-Reply-To: <DsQsaY-IIPTDayxE64vupVagj4qJZps6zfS_QWoXI1I=.a22e1037-0b02-455c-afd7-e2155984209b@github.com>
References: <XA05TxDu8l_ALOe5DGrPB9zowUEuL_wyXafpUPjm2gs=.4f39a29e-8d67-41fd-9f3f-bde4ab837062@github.com>
 <DsQsaY-IIPTDayxE64vupVagj4qJZps6zfS_QWoXI1I=.a22e1037-0b02-455c-afd7-e2155984209b@github.com>
Message-ID: <VziSwf3lr9_i_wIzbhHxWtkp6-mXf6IVCxCI3xXG73M=.21781195-932d-41d8-94a9-72661cf10f2c@github.com>

On Wed, 4 Aug 2021 09:05:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This is another step towards better [compiler blackholes](https://shipilev.net/jvm/anatomy-quarks/27-compiler-blackholes/) support. This time, we can enable JMH to auto-detect the support and enable it, if JVM supports it. 
>> 
>> The upside is that users would have much more fidelity in benchmarks and would be be exposed to eventual default Blackhole mode early.
>> 
>> The flip side is that JDK 17+ benchmarks would suddenly become faster without any user prompt, and maybe run into higher risk for VM bugs in the new blackhole code. I have ran the entire JDK microbenchmark corpus without problems, however, so that possibility should be low.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor touchups

LGTM (Not a codetools Reviewer)

-------------

Marked as reviewed by redestad (no project role).

PR: https://git.openjdk.java.net/jmh/pull/48

From shade at openjdk.java.net  Thu Aug  5 10:22:04 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 5 Aug 2021 10:22:04 GMT
Subject: RFR: CODETOOLS-7903004: JMH: Compiler Blackholes auto-detection
 [v7]
In-Reply-To: <XA05TxDu8l_ALOe5DGrPB9zowUEuL_wyXafpUPjm2gs=.4f39a29e-8d67-41fd-9f3f-bde4ab837062@github.com>
References: <XA05TxDu8l_ALOe5DGrPB9zowUEuL_wyXafpUPjm2gs=.4f39a29e-8d67-41fd-9f3f-bde4ab837062@github.com>
Message-ID: <VaXmKQN-ri9y5vlyRwRTURfWCYz57SnqjF117vKsJB8=.d2553bb7-06f3-4af5-8c47-2b26eb48f2bf@github.com>

> This is another step towards better [compiler blackholes](https://shipilev.net/jvm/anatomy-quarks/27-compiler-blackholes/) support. This time, we can teach JMH to auto-detect the support. This improves the UX by asking users to supply `-Djmh.blackhole.autoDetect` for this experimental machinery to work. This would then use compiler blackholes for JDK 17+ and full blackholes for everything else. It would also check that compiler blackholes are available when users force it.
> 
> All in all, this prevents from accidentally enabling compiler blackholes for JVMs that do not support it, and allows for a consistent JMH invocation line across all JVM versions.
> 
> We would explore enabling auto-detection by default at the later time.

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Chicken out: make auto-detect false by default, leave everything else intact

-------------

Changes:
  - all: https://git.openjdk.java.net/jmh/pull/48/files
  - new: https://git.openjdk.java.net/jmh/pull/48/files/40542021..c91d5d61

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jmh&pr=48&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jmh&pr=48&range=05-06

  Stats: 12 lines in 1 file changed: 4 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jmh/pull/48.diff
  Fetch: git fetch https://git.openjdk.java.net/jmh pull/48/head:pull/48

PR: https://git.openjdk.java.net/jmh/pull/48

From shade at openjdk.java.net  Thu Aug  5 10:51:41 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 5 Aug 2021 10:51:41 GMT
Subject: RFR: CODETOOLS-7903008: JMH: Support incremental annotation
 processing for Gradle Java plugin
In-Reply-To: <8eHsfvcEomVxu8CFXIUmgnLnZe21YCZ5vnnwfKu5L0k=.9b33608f-babd-44b8-8ddf-26f9e5a0a072@github.com>
References: <8eHsfvcEomVxu8CFXIUmgnLnZe21YCZ5vnnwfKu5L0k=.9b33608f-babd-44b8-8ddf-26f9e5a0a072@github.com>
Message-ID: <-gpEwD4r5WPkWdc5lsW1nXR3fA1U3qLXppglUuGELsE=.f8e2b124-22a3-4585-a781-e7778f047352@github.com>

On Thu, 10 Jun 2021 17:53:42 GMT, Taylor Wicksell <github.com+301239+twicksell at openjdk.org> wrote:

> This change adds support for Gradle's [incremental annotation processing](https://docs.gradle.org/current/userguide/java_plugin.html#sec:incremental_annotation_processing). Without this support, developers using the JMH annotation processor in their Gradle projects will see their compilation time increased due to Gradle invalidating its incremental compilation cache.

Although there is no first-class support for Gradle in JMH, adding this piece of metadata should not hurt. I think JMH annotation processors satisfy the requirements of Gradle Java plugin.

How did you test it?

-------------

Marked as reviewed by shade (Committer).

PR: https://git.openjdk.java.net/jmh/pull/43

From github.com+301239+twicksell at openjdk.java.net  Thu Aug  5 21:22:40 2021
From: github.com+301239+twicksell at openjdk.java.net (Taylor Wicksell)
Date: Thu, 5 Aug 2021 21:22:40 GMT
Subject: RFR: CODETOOLS-7903008: JMH: Support incremental annotation
 processing for Gradle Java plugin
In-Reply-To: <8eHsfvcEomVxu8CFXIUmgnLnZe21YCZ5vnnwfKu5L0k=.9b33608f-babd-44b8-8ddf-26f9e5a0a072@github.com>
References: <8eHsfvcEomVxu8CFXIUmgnLnZe21YCZ5vnnwfKu5L0k=.9b33608f-babd-44b8-8ddf-26f9e5a0a072@github.com>
Message-ID: <q014O7iytY8aluP3UOXJM1tnokkZXqvWxFrFE1XVAYc=.dab487a1-f46f-4834-a759-f5420eeed1ba@github.com>

On Thu, 10 Jun 2021 17:53:42 GMT, Taylor Wicksell <github.com+301239+twicksell at openjdk.org> wrote:

> This change adds support for Gradle's [incremental annotation processing](https://docs.gradle.org/current/userguide/java_plugin.html#sec:incremental_annotation_processing). Without this support, developers using the JMH annotation processor in their Gradle projects will see their compilation time increased due to Gradle invalidating its incremental compilation cache.

Unfortunately I had to test this manually by performing a `mvn install` of my branch and using that with a couple of my own gradle projects.  If you run gradle with `--info` and you will see:

Full recompilation is required because org.openjdk.jmh.generators.BenchmarkProcessor is not incremental. Analysis took 0.085 secs.


After applying this change, you will see:

Created classpath snapshot for incremental compilation in 0.391 secs. 1153 duplicate classes found in classpath (see all with --debug).


I don't have a great way to add a test case to JMH for this, as I suspect you wouldn't want all of those gradle specifics as part of your build. But open to suggestions here.

-------------

PR: https://git.openjdk.java.net/jmh/pull/43

From github.com+301239+twicksell at openjdk.java.net  Thu Aug  5 23:14:40 2021
From: github.com+301239+twicksell at openjdk.java.net (Taylor Wicksell)
Date: Thu, 5 Aug 2021 23:14:40 GMT
Subject: RFR: CODETOOLS-7903008: JMH: Support incremental annotation
 processing for Gradle Java plugin
In-Reply-To: <8eHsfvcEomVxu8CFXIUmgnLnZe21YCZ5vnnwfKu5L0k=.9b33608f-babd-44b8-8ddf-26f9e5a0a072@github.com>
References: <8eHsfvcEomVxu8CFXIUmgnLnZe21YCZ5vnnwfKu5L0k=.9b33608f-babd-44b8-8ddf-26f9e5a0a072@github.com>
Message-ID: <SWx_VWaKiu4Dus8Fh1p2CXj9y74WvLFliGY3QnUDOnA=.ec210af3-c529-4764-a5a7-6f5618986878@github.com>

On Thu, 10 Jun 2021 17:53:42 GMT, Taylor Wicksell <github.com+301239+twicksell at openjdk.org> wrote:

> This change adds support for Gradle's [incremental annotation processing](https://docs.gradle.org/current/userguide/java_plugin.html#sec:incremental_annotation_processing). Without this support, developers using the JMH annotation processor in their Gradle projects will see their compilation time increased due to Gradle invalidating its incremental compilation cache.

Please hold off on merging. After running through some more complex benchmark examples, I've found a place where we are not using Filer to write classes. `StateObjectHandler.writeStateOverrides` seems problematic. Looking to see if I can fix that.

-------------

PR: https://git.openjdk.java.net/jmh/pull/43

From duke at openjdk.java.net  Fri Aug  6 07:19:58 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 6 Aug 2021 07:19:58 GMT
Subject: git: openjdk/jmh: 7903004: JMH: Compiler Blackholes auto-detection
Message-ID: <d1123981-5962-4951-833a-0611f115f86c@openjdk.java.net>

Changeset: b8f1d778
Author:    Aleksey Shipil?v <shade at redhat.com>
Committer: GitHub <noreply at github.com>
Date:      2021-08-06 10:19:30 +0000
URL:       https://git.openjdk.java.net/jmh/commit/b8f1d778a46bb8d949bbfff6ee8e238d3b4455b1

7903004: JMH: Compiler Blackholes auto-detection


! jmh-core/src/main/java/org/openjdk/jmh/runner/CompilerHints.java
! jmh-core/src/main/java/org/openjdk/jmh/runner/format/TextReportFormat.java


From shade at openjdk.java.net  Fri Aug  6 07:22:42 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 6 Aug 2021 07:22:42 GMT
Subject: Withdrawn: CODETOOLS-7903004: JMH: Compiler Blackholes auto-detection
In-Reply-To: <XA05TxDu8l_ALOe5DGrPB9zowUEuL_wyXafpUPjm2gs=.4f39a29e-8d67-41fd-9f3f-bde4ab837062@github.com>
References: <XA05TxDu8l_ALOe5DGrPB9zowUEuL_wyXafpUPjm2gs=.4f39a29e-8d67-41fd-9f3f-bde4ab837062@github.com>
Message-ID: <Q94vLzB171PW2bosyAqZV7LM9y0MK_n9cEQGqKAqJLk=.0275bd2b-af87-4a85-be7d-d21bc41f972e@github.com>

On Mon, 2 Aug 2021 08:39:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This is another step towards better [compiler blackholes](https://shipilev.net/jvm/anatomy-quarks/27-compiler-blackholes/) support. This time, we can teach JMH to auto-detect the support. This improves the UX by asking users to supply `-Djmh.blackhole.autoDetect` for this experimental machinery to work. This would then use compiler blackholes for JDK 17+ and full blackholes for everything else. It would also check that compiler blackholes are available when users force it.
> 
> All in all, this prevents from accidentally enabling compiler blackholes for JVMs that do not support it, and allows for a consistent JMH invocation line across all JVM versions.
> 
> We would explore enabling auto-detection by default at the later time.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jmh/pull/48

From shade at openjdk.java.net  Fri Aug  6 07:25:43 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 6 Aug 2021 07:25:43 GMT
Subject: RFR: CODETOOLS-7903008: JMH: Support incremental annotation
 processing for Gradle Java plugin
In-Reply-To: <SWx_VWaKiu4Dus8Fh1p2CXj9y74WvLFliGY3QnUDOnA=.ec210af3-c529-4764-a5a7-6f5618986878@github.com>
References: <8eHsfvcEomVxu8CFXIUmgnLnZe21YCZ5vnnwfKu5L0k=.9b33608f-babd-44b8-8ddf-26f9e5a0a072@github.com>
 <SWx_VWaKiu4Dus8Fh1p2CXj9y74WvLFliGY3QnUDOnA=.ec210af3-c529-4764-a5a7-6f5618986878@github.com>
Message-ID: <GPnkztkxg7lLXpPt44-9gz-QxGidzql4XHO3t4IJxdQ=.6b6c25f6-f6d1-4659-827e-fb5872e78ef0@github.com>

On Thu, 5 Aug 2021 23:12:22 GMT, Taylor Wicksell <github.com+301239+twicksell at openjdk.org> wrote:

> Please hold off on merging. After running through some more complex benchmark examples, I've found a place where we are not using Filer to write classes. `StateObjectHandler.writeStateOverrides` seems problematic. Looking to see if I can fix that.

I don't see a problem there? `StateObjectHandler.writeStateOverrides` delegates to `GeneratorDestination.newClass`, which in calls `APGeneratorDestination.newClass` in annotation processing mode, which uses `Filer`.

-------------

PR: https://git.openjdk.java.net/jmh/pull/43

From shade at redhat.com  Mon Aug  9 10:32:25 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 9 Aug 2021 13:32:25 +0300
Subject: JMH 1.33
Message-ID: <f8a8ca7f-9d51-1495-16e0-3d4acafe3cb4@redhat.com>

Hi,

JMH 1.33 is released and available at Maven Central. This is a maintenance release, and it contains 
the following fixes:

  *) Next step in Compiler Blackholes support: JMH should now be able to auto-detect the JVM 
support. Look at benchmark configuration logs for the option name. This option is still opt-in: you 
can ask for auto-detection, and then JMH would select the blackhole mode that fits the current JVM. 
As the bonus, if you force the compiler blackholes and they are not available, the JMH would refuse 
to run. In the future, we would consider enable the auto-detection by default.
    7903004: JMH: Compiler Blackholes auto-detection

  *) Interrupt mechanics was fixed a bit to avoid failures when benchmarks are not responding to 
interrupts well. Due to the harness bugs, these interrupts potentially break the harness itself 
(observably, failing the benchmark). Plus, it has a slightly better UX.
    7903001: JMH: The interrupt to time-outing benchmark can be delivered to warmdown latches
    7903003: JMH: Print a single interruption message per iteration

Enjoy!

-- 
Thanks,
-Aleksey


From github.com+301239+twicksell at openjdk.java.net  Wed Aug 25 21:57:03 2021
From: github.com+301239+twicksell at openjdk.java.net (Taylor Wicksell)
Date: Wed, 25 Aug 2021 21:57:03 GMT
Subject: RFR: CODETOOLS-7903008: JMH: Support incremental annotation
 processing for Gradle Java plugin [v2]
In-Reply-To: <8eHsfvcEomVxu8CFXIUmgnLnZe21YCZ5vnnwfKu5L0k=.9b33608f-babd-44b8-8ddf-26f9e5a0a072@github.com>
References: <8eHsfvcEomVxu8CFXIUmgnLnZe21YCZ5vnnwfKu5L0k=.9b33608f-babd-44b8-8ddf-26f9e5a0a072@github.com>
Message-ID: <6JS-hHWo9C4KeXJdyMS6sqnvGG724hb1qqJH9I5SVGA=.b0cd1409-0540-4e3c-94ad-950f5652d100@github.com>

> This change adds support for Gradle's [incremental annotation processing](https://docs.gradle.org/current/userguide/java_plugin.html#sec:incremental_annotation_processing). Without this support, developers using the JMH annotation processor in their Gradle projects will see their compilation time increased due to Gradle invalidating its incremental compilation cache.

Taylor Wicksell 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:

  Adds support for Gradle's incremental annotation processing

-------------

Changes:
  - all: https://git.openjdk.java.net/jmh/pull/43/files
  - new: https://git.openjdk.java.net/jmh/pull/43/files/fb9b5c01..436b4281

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jmh&pr=43&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jmh&pr=43&range=00-01

  Stats: 19 lines in 7 files changed: 6 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jmh/pull/43.diff
  Fetch: git fetch https://git.openjdk.java.net/jmh pull/43/head:pull/43

PR: https://git.openjdk.java.net/jmh/pull/43

From github.com+301239+twicksell at openjdk.java.net  Wed Aug 25 22:08:00 2021
From: github.com+301239+twicksell at openjdk.java.net (Taylor Wicksell)
Date: Wed, 25 Aug 2021 22:08:00 GMT
Subject: RFR: CODETOOLS-7903008: JMH: Support incremental annotation
 processing for Gradle Java plugin [v3]
In-Reply-To: <8eHsfvcEomVxu8CFXIUmgnLnZe21YCZ5vnnwfKu5L0k=.9b33608f-babd-44b8-8ddf-26f9e5a0a072@github.com>
References: <8eHsfvcEomVxu8CFXIUmgnLnZe21YCZ5vnnwfKu5L0k=.9b33608f-babd-44b8-8ddf-26f9e5a0a072@github.com>
Message-ID: <7cCpgidZnYkE2P_0gXFrTt8Gj6uiN12l75Izp5ffNRY=.88e79cad-aab4-4d31-95ce-80e822785563@github.com>

> This change adds support for Gradle's [incremental annotation processing](https://docs.gradle.org/current/userguide/java_plugin.html#sec:incremental_annotation_processing). Without this support, developers using the JMH annotation processor in their Gradle projects will see their compilation time increased due to Gradle invalidating its incremental compilation cache.

Taylor Wicksell 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:

  Adds support for Gradle's incremental annotation processing

-------------

Changes:
  - all: https://git.openjdk.java.net/jmh/pull/43/files
  - new: https://git.openjdk.java.net/jmh/pull/43/files/436b4281..05914fec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jmh&pr=43&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jmh&pr=43&range=01-02

  Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jmh/pull/43.diff
  Fetch: git fetch https://git.openjdk.java.net/jmh pull/43/head:pull/43

PR: https://git.openjdk.java.net/jmh/pull/43

From github.com+301239+twicksell at openjdk.java.net  Wed Aug 25 22:13:42 2021
From: github.com+301239+twicksell at openjdk.java.net (Taylor Wicksell)
Date: Wed, 25 Aug 2021 22:13:42 GMT
Subject: RFR: CODETOOLS-7903008: JMH: Support incremental annotation
 processing for Gradle Java plugin
In-Reply-To: <GPnkztkxg7lLXpPt44-9gz-QxGidzql4XHO3t4IJxdQ=.6b6c25f6-f6d1-4659-827e-fb5872e78ef0@github.com>
References: <8eHsfvcEomVxu8CFXIUmgnLnZe21YCZ5vnnwfKu5L0k=.9b33608f-babd-44b8-8ddf-26f9e5a0a072@github.com>
 <SWx_VWaKiu4Dus8Fh1p2CXj9y74WvLFliGY3QnUDOnA=.ec210af3-c529-4764-a5a7-6f5618986878@github.com>
 <GPnkztkxg7lLXpPt44-9gz-QxGidzql4XHO3t4IJxdQ=.6b6c25f6-f6d1-4659-827e-fb5872e78ef0@github.com>
Message-ID: <bEk962zJlgmpDhZ9CPq6WYpIyu_LA0GjTGsbC5mip9M=.e3d1c254-b572-4abd-add1-83a206d82dd7@github.com>

On Fri, 6 Aug 2021 07:23:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Please hold off on merging. After running through some more complex benchmark examples, I've found a place where we are not using Filer to write classes. `StateObjectHandler.writeStateOverrides` seems problematic. Looking to see if I can fix that.
>
>> Please hold off on merging. After running through some more complex benchmark examples, I've found a place where we are not using Filer to write classes. `StateObjectHandler.writeStateOverrides` seems problematic. Looking to see if I can fix that.
> 
> I don't see a problem there? `StateObjectHandler.writeStateOverrides` delegates to `GeneratorDestination.newClass`, which in calls `APGeneratorDestination.newClass` in annotation processing mode, which uses `Filer`.

Sorry for the delay @shipilev this took a fair bit of time to dig through. The error I encountered here I believe is a gradle bug with the Aggregating strategy, as it only occurs on some of the later versions of Gradle. I can share a test harness if you're interested, but essentially you need to trigger incremental compilation for a class *other* than a JMH benchmark to observe the failure.  

I was unable to find a helpful solution on the Gradle side and the code does not have very much (any) documentation to assist with understanding what assumptions Gradle's incremental compiler has made. Instead, I was able to resolve this by using the Isolating strategy, which unfortunately required a change to JMH to pass the originating elements to the `Filer` when creating new classes. The end result is better overall from the perspective of providing useful information to the compiler, and according to Gradle should be more performant. However, I did have to make some changes to allow for passing this information. 

I tried to do this with as little refactoring as possible, but please let me know what you think.

-------------

PR: https://git.openjdk.java.net/jmh/pull/43

From github.com+604196+eikemeier at openjdk.java.net  Tue Aug 31 19:30:06 2021
From: github.com+604196+eikemeier at openjdk.java.net (Oliver Eikemeier)
Date: Tue, 31 Aug 2021 19:30:06 GMT
Subject: RFR: Update JOpt Simple to 5.0.4
Message-ID: <I2Qb4bM5hHV1yFFNwewyJMjydFLkhWeUD6uF13z-onQ=.d912064b-5588-436f-bee0-09794038350e@github.com>

JMH is incompatible with a recent JOpt Simple, which is easy to pull in as a dependency.

Demonstration of the problem: https://github.com/eikemeier/jmh-test

-------------

Commit messages:
 - Update JOpt Simple to 5.0.4

Changes: https://git.openjdk.java.net/jmh/pull/49/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jmh&pr=49&range=00
  Stats: 589 lines in 29 files changed: 50 ins; 0 del; 539 mod
  Patch: https://git.openjdk.java.net/jmh/pull/49.diff
  Fetch: git fetch https://git.openjdk.java.net/jmh pull/49/head:pull/49

PR: https://git.openjdk.java.net/jmh/pull/49

From shade at openjdk.java.net  Tue Aug 31 19:30:07 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 31 Aug 2021 19:30:07 GMT
Subject: RFR: Update JOpt Simple to 5.0.4
In-Reply-To: <I2Qb4bM5hHV1yFFNwewyJMjydFLkhWeUD6uF13z-onQ=.d912064b-5588-436f-bee0-09794038350e@github.com>
References: <I2Qb4bM5hHV1yFFNwewyJMjydFLkhWeUD6uF13z-onQ=.d912064b-5588-436f-bee0-09794038350e@github.com>
Message-ID: <HXoaBfNQiaPfzCmrGDQ0JICWzTrYjzjKYs364b--l1s=.817cb5b2-9cfa-4d6a-8b22-ce05fb1f4dad@github.com>

On Thu, 12 Aug 2021 19:38:20 GMT, Oliver Eikemeier <github.com+604196+eikemeier at openjdk.org> wrote:

> JMH is incompatible with a recent JOpt Simple, which is easy to pull in as a dependency.
> 
> Demonstration of the problem: https://github.com/eikemeier/jmh-test

Marked as reviewed by shade (Committer).

Frankly, it looks more like a project configuration issue. Downstream projects that depend on `jmh-core` should not have a dependency on another `jopt-simple`. If they do depend on `jopt-simple` 5.0.4 via the parent POMs or something, then they need to use `<exclusion>` to exclude older `jopt-simple` and let JMH use its own.

-------------

PR: https://git.openjdk.java.net/jmh/pull/49

From github.com+604196+eikemeier at openjdk.java.net  Tue Aug 31 19:30:08 2021
From: github.com+604196+eikemeier at openjdk.java.net (Oliver Eikemeier)
Date: Tue, 31 Aug 2021 19:30:08 GMT
Subject: RFR: Update JOpt Simple to 5.0.4
In-Reply-To: <HXoaBfNQiaPfzCmrGDQ0JICWzTrYjzjKYs364b--l1s=.817cb5b2-9cfa-4d6a-8b22-ce05fb1f4dad@github.com>
References: <I2Qb4bM5hHV1yFFNwewyJMjydFLkhWeUD6uF13z-onQ=.d912064b-5588-436f-bee0-09794038350e@github.com>
 <HXoaBfNQiaPfzCmrGDQ0JICWzTrYjzjKYs364b--l1s=.817cb5b2-9cfa-4d6a-8b22-ce05fb1f4dad@github.com>
Message-ID: <hO0RbbA3Yegh5XtLGD4RsNXrA6LrUDMvAIxkt0ZjThg=.583a9c9d-44ba-4f26-977a-8dadaab4c369@github.com>

On Wed, 18 Aug 2021 07:38:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Downstream projects that depend on `jmh-core` should not have a dependency on another `jopt-simple`.

Why? Let's assume I want to benchmark [`avro-tools`](https://mvnrepository.com/artifact/org.apache.avro/avro-tools/1.10.2) and pass command line parameters while calling `main`. Does this mean any such use case is out of scope for `jmh`?

>  If they do depend on `jopt-simple` 5.0.4 via the parent POMs or something, then they need to use `<exclusion>` to exclude older `jopt-simple` and let JMH use its own.

You can't, because they are needed in the benchmarked part. The easy solution would be to upgrade `jopt-simple`, because it's a pretty old library and everyone else is using 5.0.4 (4.6 is ancient), a more elaborate solution would be to shadow `jopt-simple` in `jmh`.

-------------

PR: https://git.openjdk.java.net/jmh/pull/49

From github.com+5225653+isker at openjdk.java.net  Tue Aug 31 20:22:12 2021
From: github.com+5225653+isker at openjdk.java.net (Ian Kerins)
Date: Tue, 31 Aug 2021 20:22:12 GMT
Subject: RFR: CODETOOLS-7903000: JMH: Fix error message for @Setup helpers on
 a class missing @State
Message-ID: <gctg91h5ZYE64qJaOOp5wzik9-nLzSussvipqhCBf8E=.e5f4c826-80b7-4e9a-b794-7a12f8bd77be@github.com>

Such error messages previously incorrectly referred to `@TearDown`.

-------------

Commit messages:
 - Fix error message for @Setup helpers on a class missing @State

Changes: https://git.openjdk.java.net/jmh/pull/44/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jmh&pr=44&range=00
  Issue: https://bugs.openjdk.java.net/browse/CODETOOLS-7903000
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jmh/pull/44.diff
  Fetch: git fetch https://git.openjdk.java.net/jmh pull/44/head:pull/44

PR: https://git.openjdk.java.net/jmh/pull/44

From github.com+5225653+isker at openjdk.java.net  Tue Aug 31 20:22:12 2021
From: github.com+5225653+isker at openjdk.java.net (Ian Kerins)
Date: Tue, 31 Aug 2021 20:22:12 GMT
Subject: RFR: CODETOOLS-7903000: JMH: Fix error message for @Setup helpers
 on a class missing @State
In-Reply-To: <gctg91h5ZYE64qJaOOp5wzik9-nLzSussvipqhCBf8E=.e5f4c826-80b7-4e9a-b794-7a12f8bd77be@github.com>
References: <gctg91h5ZYE64qJaOOp5wzik9-nLzSussvipqhCBf8E=.e5f4c826-80b7-4e9a-b794-7a12f8bd77be@github.com>
Message-ID: <BQQ83NGSuYEC4t7a3Sn-hHZyPGJRs3lyfX1oXE2k0tw=.cfdcb5d0-771f-4894-ad2a-4372be951147@github.com>

On Fri, 30 Jul 2021 01:54:26 GMT, Ian Kerins <github.com+5225653+isker at openjdk.org> wrote:

> Such error messages previously incorrectly referred to `@TearDown`.

Looking into it.

-------------

PR: https://git.openjdk.java.net/jmh/pull/44

From shade at openjdk.java.net  Tue Aug 31 20:22:12 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 31 Aug 2021 20:22:12 GMT
Subject: RFR: CODETOOLS-7903000: JMH: Fix error message for @Setup helpers
 on a class missing @State
In-Reply-To: <gctg91h5ZYE64qJaOOp5wzik9-nLzSussvipqhCBf8E=.e5f4c826-80b7-4e9a-b794-7a12f8bd77be@github.com>
References: <gctg91h5ZYE64qJaOOp5wzik9-nLzSussvipqhCBf8E=.e5f4c826-80b7-4e9a-b794-7a12f8bd77be@github.com>
Message-ID: <SIh2B1cs6xJ_EVCi6hBGi4Dgu3YHflrAXfe4Y41fMjo=.1d7ce6ca-0d3c-4bcd-9bd7-5d953c4260f3@github.com>

On Fri, 30 Jul 2021 01:54:26 GMT, Ian Kerins <github.com+5225653+isker at openjdk.org> wrote:

> Such error messages previously incorrectly referred to `@TearDown`.

Thank you, this looks fine. We need OCA to clear before bots allow you to integrate.

-------------

Marked as reviewed by shade (Committer).

PR: https://git.openjdk.java.net/jmh/pull/44