RFC: C1/C2 support for Blackholes

[Brian Goetz]

> 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.

To put it another way: if this feature is "experimental", what are the 
plans to have it eventually graduate from that status, since 
"experimental" should not be (though sometimes has been) a permanent 
state.  There is precedent for public API point that "do nothing" (such 
as `reachabilityFence`) but provide hints to the VM, and as you point 
out, having one common way to do this is better than each JVM having its 
own way to do this.  It may be too early to make this choice, but it's 
not too early to start thinking about the options, so I'm glad to see 
this discussion restarted.

> 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 
>

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.

> === 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".

Agree.  This feels like an experimental feature (we're still evaluating 
how it works) and it does not feel like a diagnostic feature (these are 
intended for diagnosis of the VM, not user code.)

> 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?

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.)