RFR: 8259316: [REDO] C1/C2 compiler support for blackholes [v5]

[Danila Malyutin]

On Wed, 5 May 2021 12:00:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This reworks the compiler support for blackholes. The key difference against the last version (#1203) is that blackholes are only acceptable as empty static methods, which both simplifies the implementation and eliminates a few compatibility questions.
>> 
>> JMH uses the `Blackhole::consume` methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks. 
>> 
>> Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its `Blackhole` methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. See CSR and related discussion for alternatives and future plans.
>> 
>> C1 code is platform-independent, and it handles blackhole via the intrinsics paths, lowering it to nothing.
>> 
>> C2 makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. It also seems to require the least fiddling with C2 internals.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:
> 
>  - Merge branch 'master' into JDK-8259316-blackholes-redo
>  - Remove @build in favor of @library
>  - Update copyrights where needed
>  - Add vm.flagless requirement to tests
>  - Stray whitespace
>  - Merge branch 'master' into JDK-8259316-blackholes-redo
>  - Merge branch 'master' into JDK-8259316-blackholes-redo
>  - Redo BlackholeIntrinsicTest to see if target blackhole methods were indeed intrinsified
>  - Rename BlackholeStaticTest to BlackholeIntrinsicTest
>  - BlackholeStaticTest should unlock blackholes
>  - ... and 17 more: https://git.openjdk.java.net/jdk/compare/65ce4d20...65e865aa

src/hotspot/share/ci/ciMethod.cpp line 158:

> 156: #endif
> 157: 
> 158:   CompilerOracle::tag_blackhole_if_possible(h_m);

Is there a reason for why not updating `_intrinsic_id = h_m->intrinsic_id();` with the potentially updated id after calling this is fine?
Wouldn't it still contain the old id set here (at least for the first instance): https://github.com/openjdk/jdk/pull/2024/files#diff-c08baec11bce860df907b1edd944889e3778519fdd7c7a5b9d00e10eb267667fR84 ?

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

PR: https://git.openjdk.java.net/jdk/pull/2024