RFC: C1/C2 support for Blackholes

Aleksey Shipilev shade at redhat.com
Thu Mar 25 14:50:05 UTC 2021

On 3/25/21 3:12 PM, Brian Goetz wrote:
> In theory, since all primitive classes will be subtypes of Object, we
> could in theory get away with a single bh(Object) method for all the
> primitive classes.  Whether that is actually true when you get down
> below the bytecode level remains to be seen.

Speaking from JMH Blackhole experience, generic boxing is no-go here.

Mostly because bh.consume(Object) tries to perform freaky/identity-sensitive operations on the 
argument, in attempt to break scalar replacement of the object. Which is exactly the opposite of 
what we want for primitive consumes: we want optimizing compilers to eliminate the box, giving us 
the unboxed value to blackhole. This is why JMH Blackhole provides primitive overloads.

So it is an open question how primitive types fit into this picture. It would be nice to answer it 
in Valhalla context, if only to make current Valhalla nano-benchmarking more precise. Something like 
explaining to JIT compilers that boxing is unnecessary in that particular case, and instead it all 
the primitive type components should be blackholed. Or some such.

> This sounds like a responsible plan.  (I assume that somewhere between
> "d" and "e" JMH acquires the ability to use both, depending on what it
> finds in the currently running VM.)

Yes, of course. Once something is public API and we are sure compiler support is sane, we can just 
default to public API when available.

Technically, that is not hard to do. JMH lets users choose between "normal" and "compiler-command" 
(experimental) Blackholes, without apparent performance degradation. That switch can be extended to 
choose the public API method too. I don't believe it would require a lot of (byte)code gymnastics: 
the "public API" path would not be taken by legacy JDKs, and so we don't have to care about 
AbstractMethodError-s and such. JCStress shows that you can even mock out some "JDK" classes to keep 
the project buildable on non-latest JDKs that do not have the methods yet.


More information about the jdk-dev mailing list