From duke at openjdk.java.net  Mon Nov  8 12:45:49 2021
From: duke at openjdk.java.net (Vsevolod Tolstopyatov)
Date: Mon, 8 Nov 2021 12:45:49 GMT
Subject: RFR: [DRAFT] Support Java literals in @Param annotation
In-Reply-To: <DY7D1G1G9UNuMZmCNXkLhtQaOJ_Vx_Osqws95I9A7yI=.488d4673-b4e1-42e5-9863-ed792a8f36bc@github.com>
References: <DY7D1G1G9UNuMZmCNXkLhtQaOJ_Vx_Osqws95I9A7yI=.488d4673-b4e1-42e5-9863-ed792a8f36bc@github.com>
Message-ID: <0ZeKOHcX_l25skxfOZhU31prjjhH3Pec8etTJtedgd4=.39e124ff-6adc-42e0-b1d7-20a91bc075f4@github.com>

On Thu, 9 Sep 2021 16:27:44 GMT, Vsevolod Tolstopyatov <duke at openjdk.java.net> wrote:

> This is a follow-up to https://mail.openjdk.java.net/pipermail/jmh-dev/2020-October/003039.html
> 
> I've prototyped it and found few corners which I'd like to highlight and discuss.
> 
> The initial purpose of the change is to be able to use underscores for the sake of better readability in both code and text reports:
> 
> `@Param("1_000", "10_000", "100_000")` 
> 
> and
> 
> 
> Benchmark        (listSize)   Mode  Cnt      Score   Error  Units
> ShowOff.consume       1_000  thrpt       42294.795          ops/s
> ShowOff.consume      10_000  thrpt        4057.322          ops/s
> ShowOff.consume     100_000  thrpt        2866.069          ops/s
> 
> 
> 
> While doing so, I've decided that it would be nice to support the strict subset of actual Java literals (at least to have a reference to point at) which has a lot of pitfalls:
> 
> * Now we have (?) to support octal, binary and hexadecimal literals
> * The actual grammar is quite wild, so literals like `0_12___3_4` are also supported
> * `l` and `L` at the end of `long` literals are not supported (it seems a bit weird to do so)
> * `NumericLiteralsParser` leaks to public API, so the generated benchmarks can invoke it (not sure what's the API policy here, but it's worth pointing it out)
> * Underscores in floating points literals are not supported, mostly because then I have to match hexadecimal literals with underscores as well. No particular reason apart from "it's extra work without clear benefits". I can implement it if it's required for the PR though.
> 
> Most importantly, support of such literals will break existing benchmarks that prefixed their numeric parameters with zero -- now they are interpreted as octal literals (and either rejected, e.g. `09` or converted to decimal, breaking the original authors intent). Previously, `X.parseX` functions (e.g. `Integer.parseInt`) were used and they are okay with leading zeroes.
> 
> Breaking change seems to be the blocker here, and I'd like to hear your opinion of the acceptable approach aligned with JMH API
> 
> Potential alternatives:
> 
> * Do nothing, don't support underscores
> * Support only decimal literals
> * Support any subset of literals (e.g. decimal and hexadecimal only)
> * Just trim all the underscores and parse it as before via `Integer.parseInt` and so on

Hi, friendly reminder in case you've accidentally missed it or interpreted `[DRAFT]` prefix as "not yet ready for discussion". It would be nice to hear the maintainer's opinion on the proposed alternatives.

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

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

From ngasson at openjdk.java.net  Thu Nov 11 03:20:07 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 11 Nov 2021 03:20:07 GMT
Subject: RFR: CODETOOLS-7903056: perfasm can report wrong stub name
Message-ID: <Xp7SsT2EpZzF8DTpqYquCL-Vn5H8gFz0Dkwq2gUs8go=.8397c7e4-036f-4089-9dfb-1d21669a587f@github.com>

This patch changes `IntervalMap::get` to check that the value falls within an interval's high/low bounds. Otherwise it returns the closest entry < value which can be misleading.

Example of the new output, where previously the `<unknown>` line reported the wrong stub routine:


 18.19%           libjvm.so  ProgrammableUpcallHandler::on_entry
 13.94%                      <unknown>
  9.39%           libjvm.so  ProgrammableUpcallHandler::on_exit
  8.36%         c2, level 4  java.lang.invoke.LambdaForm$MH.0x00000008001b8400::invoke, version 1595

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

Commit messages:
 - CODETOOLS-7903056: perfasm can report wrong stub name

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

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

From shade at openjdk.java.net  Thu Nov 11 07:03:51 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 11 Nov 2021 07:03:51 GMT
Subject: RFR: CODETOOLS-7903056: perfasm can report wrong stub name
In-Reply-To: <Xp7SsT2EpZzF8DTpqYquCL-Vn5H8gFz0Dkwq2gUs8go=.8397c7e4-036f-4089-9dfb-1d21669a587f@github.com>
References: <Xp7SsT2EpZzF8DTpqYquCL-Vn5H8gFz0Dkwq2gUs8go=.8397c7e4-036f-4089-9dfb-1d21669a587f@github.com>
Message-ID: <FqRu8NmoQBU7OclCoIkS9qkrSlO8q1WLPAfWLTo2mko=.58950247-57f6-4b99-bb1b-a05f3e63de8e@github.com>

On Thu, 11 Nov 2021 03:14:36 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> This patch changes `IntervalMap::get` to check that the value falls within an interval's high/low bounds. Otherwise it returns the closest entry < value which can be misleading.
> 
> Example of the new output, where previously the `<unknown>` line reported the wrong stub routine:
> 
> 
>  18.19%           libjvm.so  ProgrammableUpcallHandler::on_entry
>  13.94%                      <unknown>
>   9.39%           libjvm.so  ProgrammableUpcallHandler::on_exit
>   8.36%         c2, level 4  java.lang.invoke.LambdaForm$MH.0x00000008001b8400::invoke, version 1595

Changes requested by shade (Committer).

jmh-core/src/main/java/org/openjdk/jmh/util/IntervalMap.java line 42:

> 40:         @Override
> 41:         public int compareTo(Interval other) {
> 42:             return (int)(this.from - other.from);

Suggestion:

            return Long.compare(this.from, other.from);

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

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

From shade at openjdk.java.net  Thu Nov 11 07:03:52 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 11 Nov 2021 07:03:52 GMT
Subject: RFR: CODETOOLS-7903056: perfasm can report wrong stub name
In-Reply-To: <FqRu8NmoQBU7OclCoIkS9qkrSlO8q1WLPAfWLTo2mko=.58950247-57f6-4b99-bb1b-a05f3e63de8e@github.com>
References: <Xp7SsT2EpZzF8DTpqYquCL-Vn5H8gFz0Dkwq2gUs8go=.8397c7e4-036f-4089-9dfb-1d21669a587f@github.com>
 <FqRu8NmoQBU7OclCoIkS9qkrSlO8q1WLPAfWLTo2mko=.58950247-57f6-4b99-bb1b-a05f3e63de8e@github.com>
Message-ID: <sQGda2fqql4KhOfU4xCRVA-qrQGWncflT_F6PjfEiHU=.e1161ddc-1003-4d53-b47b-e53939a30390@github.com>

On Thu, 11 Nov 2021 06:57:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This patch changes `IntervalMap::get` to check that the value falls within an interval's high/low bounds. Otherwise it returns the closest entry < value which can be misleading.
>> 
>> Example of the new output, where previously the `<unknown>` line reported the wrong stub routine:
>> 
>> 
>>  18.19%           libjvm.so  ProgrammableUpcallHandler::on_entry
>>  13.94%                      <unknown>
>>   9.39%           libjvm.so  ProgrammableUpcallHandler::on_exit
>>   8.36%         c2, level 4  java.lang.invoke.LambdaForm$MH.0x00000008001b8400::invoke, version 1595
>
> jmh-core/src/main/java/org/openjdk/jmh/util/IntervalMap.java line 42:
> 
>> 40:         @Override
>> 41:         public int compareTo(Interval other) {
>> 42:             return (int)(this.from - other.from);
> 
> Suggestion:
> 
>             return Long.compare(this.from, other.from);

I also believe the Java style requires `equals` and `hashCode` that is coherent with newly added `compareTo`. Please autogenerate one in IDE, using `from` field?

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

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

From ngasson at openjdk.java.net  Thu Nov 11 07:48:13 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 11 Nov 2021 07:48:13 GMT
Subject: RFR: CODETOOLS-7903056: perfasm can report wrong stub name [v2]
In-Reply-To: <Xp7SsT2EpZzF8DTpqYquCL-Vn5H8gFz0Dkwq2gUs8go=.8397c7e4-036f-4089-9dfb-1d21669a587f@github.com>
References: <Xp7SsT2EpZzF8DTpqYquCL-Vn5H8gFz0Dkwq2gUs8go=.8397c7e4-036f-4089-9dfb-1d21669a587f@github.com>
Message-ID: <UHx48ocVyhxPBG45-wLND2bgH5ShN2JCmGuhSfZikGE=.67579548-5b4f-4328-9f48-dc7f0f8edcee@github.com>

> This patch changes `IntervalMap::get` to check that the value falls within an interval's high/low bounds. Otherwise it returns the closest entry < value which can be misleading.
> 
> Example of the new output, where previously the `<unknown>` line reported the wrong stub routine:
> 
> 
>  18.19%           libjvm.so  ProgrammableUpcallHandler::on_entry
>  13.94%                      <unknown>
>   9.39%           libjvm.so  ProgrammableUpcallHandler::on_exit
>   8.36%         c2, level 4  java.lang.invoke.LambdaForm$MH.0x00000008001b8400::invoke, version 1595

Nick Gasson has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/jmh/pull/54/files
  - new: https://git.openjdk.java.net/jmh/pull/54/files/cfa2440f..a61524e1

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

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

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

From shade at openjdk.java.net  Thu Nov 11 07:48:15 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 11 Nov 2021 07:48:15 GMT
Subject: RFR: CODETOOLS-7903056: perfasm can report wrong stub name [v2]
In-Reply-To: <UHx48ocVyhxPBG45-wLND2bgH5ShN2JCmGuhSfZikGE=.67579548-5b4f-4328-9f48-dc7f0f8edcee@github.com>
References: <Xp7SsT2EpZzF8DTpqYquCL-Vn5H8gFz0Dkwq2gUs8go=.8397c7e4-036f-4089-9dfb-1d21669a587f@github.com>
 <UHx48ocVyhxPBG45-wLND2bgH5ShN2JCmGuhSfZikGE=.67579548-5b4f-4328-9f48-dc7f0f8edcee@github.com>
Message-ID: <hRdyapTsvNbOXBkutJnrZlevd9-ncR7GozkFLPhJiYU=.b6661804-c958-43d5-ac39-6d1d81050e8d@github.com>

On Thu, 11 Nov 2021 07:44:45 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> This patch changes `IntervalMap::get` to check that the value falls within an interval's high/low bounds. Otherwise it returns the closest entry < value which can be misleading.
>> 
>> Example of the new output, where previously the `<unknown>` line reported the wrong stub routine:
>> 
>> 
>>  18.19%           libjvm.so  ProgrammableUpcallHandler::on_entry
>>  13.94%                      <unknown>
>>   9.39%           libjvm.so  ProgrammableUpcallHandler::on_exit
>>   8.36%         c2, level 4  java.lang.invoke.LambdaForm$MH.0x00000008001b8400::invoke, version 1595
>
> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Looks fine, thanks.

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

Marked as reviewed by shade (Committer).

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

From ngasson at openjdk.java.net  Thu Nov 11 10:17:53 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 11 Nov 2021 10:17:53 GMT
Subject: Integrated: CODETOOLS-7903056: perfasm can report wrong stub name
In-Reply-To: <Xp7SsT2EpZzF8DTpqYquCL-Vn5H8gFz0Dkwq2gUs8go=.8397c7e4-036f-4089-9dfb-1d21669a587f@github.com>
References: <Xp7SsT2EpZzF8DTpqYquCL-Vn5H8gFz0Dkwq2gUs8go=.8397c7e4-036f-4089-9dfb-1d21669a587f@github.com>
Message-ID: <Y1gZ3Qv3bdHEVB0589XqRbnmbVsR4voEUvPnUBm97Ck=.faedada8-6eb7-41dd-860e-265576a2bdbc@github.com>

On Thu, 11 Nov 2021 03:14:36 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> This patch changes `IntervalMap::get` to check that the value falls within an interval's high/low bounds. Otherwise it returns the closest entry < value which can be misleading.
> 
> Example of the new output, where previously the `<unknown>` line reported the wrong stub routine:
> 
> 
>  18.19%           libjvm.so  ProgrammableUpcallHandler::on_entry
>  13.94%                      <unknown>
>   9.39%           libjvm.so  ProgrammableUpcallHandler::on_exit
>   8.36%         c2, level 4  java.lang.invoke.LambdaForm$MH.0x00000008001b8400::invoke, version 1595

This pull request has now been integrated.

Changeset: 25860b32
Author:    Nick Gasson <ngasson at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jmh/commit/25860b326dd681f4442124d64b2f75aa31cb70ba
Stats:     52 lines in 1 file changed: 46 ins; 0 del; 6 mod

7903056: perfasm can report wrong stub name

Reviewed-by: shade

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

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

From shade at openjdk.java.net  Tue Nov 30 10:10:37 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 30 Nov 2021 10:10:37 GMT
Subject: RFR: CODETOOLS-7903068: JMH: Enable compiler blackholes by default,
 if available
Message-ID: <EBaYcaieGkiFSVKKySouAe1NLtZRxRphdis2ZxvLrfc=.4f3b3f48-bf63-470f-9ba4-8ed90fd039a8@github.com>

With the release of JDK 17, we can finally consider enabling [compiler blackholes](https://shipilev.net/jvm/anatomy-quarks/27-compiler-blackholes/) by default.

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

Commit messages:
 - Fix

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

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

From shade at openjdk.java.net  Tue Nov 30 10:33:22 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 30 Nov 2021 10:33:22 GMT
Subject: RFR: [DRAFT] Support Java literals in @Param annotation
In-Reply-To: <DY7D1G1G9UNuMZmCNXkLhtQaOJ_Vx_Osqws95I9A7yI=.488d4673-b4e1-42e5-9863-ed792a8f36bc@github.com>
References: <DY7D1G1G9UNuMZmCNXkLhtQaOJ_Vx_Osqws95I9A7yI=.488d4673-b4e1-42e5-9863-ed792a8f36bc@github.com>
Message-ID: <RAqQyIunyfGMbHfP7bOO9cMJVz1ljDL6A_eIxwAEm74=.39d2b2f7-667f-4559-a3be-4b09cbe0bb0d@github.com>

On Thu, 9 Sep 2021 16:27:44 GMT, Vsevolod Tolstopyatov <duke at openjdk.java.net> wrote:

> This is a follow-up to https://mail.openjdk.java.net/pipermail/jmh-dev/2020-October/003039.html
> 
> I've prototyped it and found few corners which I'd like to highlight and discuss.
> 
> The initial purpose of the change is to be able to use underscores for the sake of better readability in both code and text reports:
> 
> `@Param("1_000", "10_000", "100_000")` 
> 
> and
> 
> 
> Benchmark        (listSize)   Mode  Cnt      Score   Error  Units
> ShowOff.consume       1_000  thrpt       42294.795          ops/s
> ShowOff.consume      10_000  thrpt        4057.322          ops/s
> ShowOff.consume     100_000  thrpt        2866.069          ops/s
> 
> 
> 
> While doing so, I've decided that it would be nice to support the strict subset of actual Java literals (at least to have a reference to point at) which has a lot of pitfalls:
> 
> * Now we have (?) to support octal, binary and hexadecimal literals
> * The actual grammar is quite wild, so literals like `0_12___3_4` are also supported
> * `l` and `L` at the end of `long` literals are not supported (it seems a bit weird to do so)
> * `NumericLiteralsParser` leaks to public API, so the generated benchmarks can invoke it (not sure what's the API policy here, but it's worth pointing it out)
> * Underscores in floating points literals are not supported, mostly because then I have to match hexadecimal literals with underscores as well. No particular reason apart from "it's extra work without clear benefits". I can implement it if it's required for the PR though.
> 
> Most importantly, support of such literals will break existing benchmarks that prefixed their numeric parameters with zero -- now they are interpreted as octal literals (and either rejected, e.g. `09` or converted to decimal, breaking the original authors intent). Previously, `X.parseX` functions (e.g. `Integer.parseInt`) were used and they are okay with leading zeroes.
> 
> Breaking change seems to be the blocker here, and I'd like to hear your opinion of the acceptable approach aligned with JMH API
> 
> Potential alternatives:
> 
> * Do nothing, don't support underscores
> * Support only decimal literals
> * Support any subset of literals (e.g. decimal and hexadecimal only)
> * Just trim all the underscores and parse it as before via `Integer.parseInt` and so on

Hi, sorry for extremely late reply. This is a tough one compatibility-wise. I think it would be safer to:

- Drop octal literals support, leave only binary, decimal, hexadecimal; they seem to be unambiguous when applied over integral types;
- Move `NumericLiteralsParser` into generated benchmark code to avoid exposure to external code; yes, that would make unit testing much less convenient, you would have to do real JMH tests in `jmh-core-it` to reach the code; and put negative tests in `jmh-core-ct`, so we can check that known-bad values are rejected at compile time;
- Need additional test to verify that `@Param` over `String` does not accidentally converts the values;
- Figure out how hard would it be to support floating-point values, I'd think this one is useful in floating-point benchmarks `HexadecimalFloatingPointLiteral HexSignificand BinaryExponent`

Don't invest much time into this, as we might run into some unknown blocker going forward, which would derail all this.

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

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

From shade at openjdk.java.net  Tue Nov 30 10:41:24 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 30 Nov 2021 10:41:24 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: <y4rF0WceoMJD_omg7iNt4X68IJowlpTHeJLOiz9voLk=.960f3872-d918-4055-9e39-190d0e489c1b@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 to be a bother, but would you mind having another look at this one @shipilev?

Hi! Sorry for delay. This looks marginally okay, although I was getting a bit nervous about implementing new stuff to support (unsupported) Gradle builds. But I think this is okay. 

Now that it affects core code, we have to figure out a bit of testing. Please merge from the `master`, and see if https://github.com/twicksell/jmh/actions have workflows enabled for this PR. Those should be green.

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

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

From shade at openjdk.java.net  Tue Nov 30 16:06:54 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 30 Nov 2021 16:06:54 GMT
Subject: RFR: CODETOOLS-7903068: JMH: Enable compiler blackholes by
 default, if available [v2]
In-Reply-To: <EBaYcaieGkiFSVKKySouAe1NLtZRxRphdis2ZxvLrfc=.4f3b3f48-bf63-470f-9ba4-8ed90fd039a8@github.com>
References: <EBaYcaieGkiFSVKKySouAe1NLtZRxRphdis2ZxvLrfc=.4f3b3f48-bf63-470f-9ba4-8ed90fd039a8@github.com>
Message-ID: <hBLDl78_owPY6acY3S6iRnc07bZB6JLm8bUB0Hv7Jxc=.f58447a4-df9c-42fb-9bd0-d0efb935e7ae@github.com>

> With the release of JDK 17, we can finally consider enabling [compiler blackholes](https://shipilev.net/jvm/anatomy-quarks/27-compiler-blackholes/) by default.

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

  Reconcile the meaning of "default" Blackhole mode

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

Changes:
  - all: https://git.openjdk.java.net/jmh/pull/57/files
  - new: https://git.openjdk.java.net/jmh/pull/57/files/8ada9f99..47828f8a

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

  Stats: 6 lines in 1 file changed: 1 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jmh/pull/57.diff
  Fetch: git fetch https://git.openjdk.java.net/jmh pull/57/head:pull/57

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

From duke at openjdk.java.net  Tue Nov 30 16:48:24 2021
From: duke at openjdk.java.net (duke)
Date: Tue, 30 Nov 2021 16:48:24 GMT
Subject: git: openjdk/jmh: 7903068: JMH: Enable compiler blackholes by default, 
 if available
Message-ID: <86f8d73e-be88-44ae-bf9c-2776bc41c61a@openjdk.java.net>

Changeset: fcf18d57
Author:    Aleksey Shipil?v <shade at redhat.com>
Committer: GitHub <noreply at github.com>
Date:      2021-11-30 17:47:30 +0000
URL:       https://git.openjdk.java.net/jmh/commit/fcf18d57852cf00c88a8da5c947c6afc0505cba9

7903068: JMH: Enable compiler blackholes by default, if available


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


From shade at openjdk.java.net  Tue Nov 30 16:50:22 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 30 Nov 2021 16:50:22 GMT
Subject: Withdrawn: CODETOOLS-7903068: JMH: Enable compiler blackholes by
 default, if available
In-Reply-To: <EBaYcaieGkiFSVKKySouAe1NLtZRxRphdis2ZxvLrfc=.4f3b3f48-bf63-470f-9ba4-8ed90fd039a8@github.com>
References: <EBaYcaieGkiFSVKKySouAe1NLtZRxRphdis2ZxvLrfc=.4f3b3f48-bf63-470f-9ba4-8ed90fd039a8@github.com>
Message-ID: <ou7DgbscmOKbj0BevmKfsW26KODcOFr3QeayfOt6otU=.ceb8af18-0862-4365-b292-d1cf7ed1c82a@github.com>

On Tue, 30 Nov 2021 10:06:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> With the release of JDK 17, we can finally consider enabling [compiler blackholes](https://shipilev.net/jvm/anatomy-quarks/27-compiler-blackholes/) by default.

This pull request has been closed without being integrated.

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

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