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.
--
Thanks,
-Aleksey
More information about the jdk-dev
mailing list