Description
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
Attachments
Issue Links
- 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