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:
https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153
While it was proved useful for many years, it unfortunately comes with several major drawbacks:
1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds.
2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X.
3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance.
Supporting this directly in compilers would improve nanobenchmark fidelity.
Instead of introducing public APIs, 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. This is being prototyped as
Dirty C1/C2 prototype that handles all arguments to "blackholed" method:
https://github.com/openjdk/jdk/pull/2024
It makes Blackholes behave substantially better:
http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png
- causes
- 
                    JDK-8344251 C2: remove blackholes with dead control input -           
- Resolved
 
-         
- csr for
- 
                    JDK-8264133 [REDO] C1/C2 compiler support for blackholes -           
- Closed
 
-         
- relates to
- 
                    JDK-8285394 Compiler blackholes can be eliminated due to stale ciMethod::intrinsic_id() -           
- Resolved
 
-         
- 
                    JDK-8252505 C1/C2 compiler support for blackholes -           
- Resolved
 
-         
- 
                    JDK-8266573 Make sure blackholes are tagged for all JVMCI paths -           
- Resolved
 
-         
- 
                    JDK-8267791 [lworld][lw3] Support compiler blackholes for inline types -           
- Resolved
 
-         
- 
                    JDK-8273335 compiler/blackhole tests should not run with interpreter-only VMs -           
- Resolved
 
-         
- 
                    JDK-8284848 C2: Compiler blackhole arguments should be treated as globally escaping -           
- Resolved
 
-         
- 
                    JDK-8296545 C2 Blackholes should allow load optimizations -           
- Resolved
 
-         
- 
                    JDK-8303069 Memory leak in CompilerOracle::parse_from_line -           
- Resolved
 
-         
- 
                    JDK-8214763 add compiler intrinsic to materialize objects -           
- Open
 
-         
 
        