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/compare/master...shipilev:JDK-8252505-blackholes
It makes Blackholes behave substantially better:
http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png
- csr for
-
JDK-8257827 C1/C2 compiler support for blackholes
- Closed
- relates to
-
JDK-8257803 Add -Xbatch to compiler/blackhole tests
- Resolved
-
JDK-8258619 -XX:CompileCommand=blackhole,* should only accept empty static methods
- Closed
-
JDK-8257805 Add compiler/blackhole tests to tier1
- Resolved
-
JDK-8257848 -XX:CompileCommand=blackhole,* should be diagnostic
- Resolved
-
CODETOOLS-7902762 JMH: Enable experimental use of "blackhole" compiler command
- Closed
-
JDK-8258558 Revert changes for JDK-8252505 and related issues
- Resolved
-
JDK-8258101 compiler/blackhole tests fail with -Xcomp
- Closed
-
JDK-8259316 [REDO] C1/C2 compiler support for blackholes
- Resolved