RFC: C1/C2 support for Blackholes
shade at redhat.com
Thu Mar 25 09:35:05 UTC 2021
Brian asked me to bring this discussion forward to jdk-dev at .
This is the "C1/C2 support for Blackholes" RFE that briefly discusses the motivation:
This is the patch that implements the RFE in both C1 and C2:
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
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:
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):
=== 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.
Based on the considerations above, these are the plans I have in mind for this feature.
a) Land the CompileCommand=blackhole support in JDK 17;
b) Maintain the CompileCommand=blackhole support in JDK 17u, backporting fixes from mainline, if any;
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?
More information about the jdk-dev