RFC: C1/C2 support for Blackholes

[Aleksey Shipilev]

Hi,

Brian asked me to bring this discussion forward to jdk-dev at .

=== Synopsis

This is the "C1/C2 support for Blackholes" RFE that briefly discusses the motivation:
   https://bugs.openjdk.java.net/browse/JDK-8259316

This is the patch that implements the RFE in both C1 and C2:
   https://github.com/openjdk/jdk/pull/2024

Aside: Graal seems to do a similar thing for quite a while, which probably means that the same JMH 
nano-benchmark on C1/C2 and Graal behave differently due to [the absence of] this infrastructure 
overhead.

The implementation discussion seems to have reached the consensus (I see some comments from Doug, 
and there are some questions about testing). The post-integration discussion seemed to revolve 
around the major question: what should the interface look like? There was a discussion in the 
retroactive CSR: https://bugs.openjdk.java.net/browse/JDK-8257827 -- which eventually lead to the 
backout from JDK 16 for reconsideration for JDK 17.

Here, I would like to have a bit of discussion about it. To start from the clean slate, I submitted 
the new CSR that captures my current thinking:
   https://bugs.openjdk.java.net/browse/JDK-8264133

This thread is probably a better way to mull over the questions without piling on less-structured 
comments onto the CSR issue. In other words, let's discuss the interface and approach here.

Current implementation introduces a new sub-command, -XX:CompileCommand=blackhole,<method>. It is 
handy, because CompileCommand is a non-standard interface that: a) allows us to experiment with the 
implementation, while leaving us the escape hatch to revert it without raising hard compatibility 
questions; and b) JMH already uses to opt-in to inline/dontline hints for its infrastructure, thus 
requiring no further work to support.

Recurrent questions about this:

=== Should this be a public API instead?

Probably yes, at some point in the future.

The experience with implementing blackhole support in C2 (and doing follow-up bugfixes) tells me 
that it is hard to get it right and clean. I did 4 iterations of C2 code, every time being 
completely sure I did it right! There are interesting failure modes if the support is implemented 
incorrectly. There are probably other not-yet-identified corner cases, which would manifest on more 
complicated code shapes.

This is why I believe real-world experimental testing is important before we even consider 
graduating this into standard public API.

While it is too early to think about how such an API would look like, I believe it would take 
similar form as what JMH ships with (probably with consideration for value^W inline^W primitive 
types and whatever other feature shows up by then):
 
https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153

=== Should this (not) be an experimental option?

We can technically turn currently-Experimental CompileCommand=blackhole into Diagnostic one, which 
would move it out of formal requirement for having the CSR. Still, it would be an abuse of the 
process to avoid the compatibility discussion.

We can technically drop the Experimental flag from CompileCommand=blackhole completely, but this 
would formally corner us into compatibility questions, should we decide to drop it (either due to 
complete failure, or due to graduation into standard public APIs).

I am leaning towards keeping CompileCommand=blackhole "Experimental".

=== Should this be available/maintained in (previous) LTSes?

Let's face it: the majority of developer population is firmly sitting on LTSes. If we want to see 
more of the real world testing in JMH that results in prompt feedback, we should probably consider 
making this available/maintained in LTSes.

This also makes performance work on LTSes quite a bit more convenient.

17u is the easiest thing to do here. If the initial patch lands in 17, we would only need to do 
touch-ups, if any. At any given point, we should be able to remove/disable the blackhole support, in 
case it runs into irreconcilable problems.

Previous LTS releases are a bit harder, because doing this kind of support would require backporting 
the initial patch. Luckily, it is not hard to do. I proved it to myself the following way: 
8u/11u/16u testing binaries I ship at builds.shipilev.net include the experimental backports of 
current patch, and they proved to be no hassle to maintain. It is still an open question whether JDK 
Updates maintainers would accept these patches upstream. Anyhow, the same stance as for 17u stands: 
at any given moment, we should be able to remove/disable it.

Experimental CompileCommand=blackhole gives us a way to retract stuff.

=== Plans

Based on the considerations above, these are the plans I have in mind for this feature.

Short-term plan:
   a) Land the CompileCommand=blackhole support in JDK 17;
   b) Maintain the CompileCommand=blackhole support in JDK 17u, backporting fixes from mainline, if any;

Middle-term plan:
   c) (optimistically) Propose the CompileCommand=blackhole support to JDK 11u and JDK 8u (and maybe 
even 15u, 13u, time permitting), backporting fixes from mainline, if any;

...and long-term plan is predicated on real-world success and stability of C1/C2 implementations. I 
would say that once JMH uses in the wild start to de-facto default to these compiler-assisted 
Blackholes, we can claim the experiment is a success. I expect it to require at least a year since 
the LTS releases.

If experiment is successful, the long-term plan kicks in:
   d) Propose the public Blackhole API;
   e) Drop the CompileCommand=blackhole support in then-current JDK releases;
   f) Continue with supporting public Blackhole APIs in then-actual LTSes;
   g) Continue with supporting CompileCommand=blackhole in previous LTSes, waiting them to die off;

If experiment fails, the recovery plan kicks in:
   h) Drop the CompileCommand=blackhole from every actively maintained JDK release;

How does all this sound?

-- 
Thanks,
-Aleksey