RFR: 8252505: C1/C2 compiler support for blackholes [v24]

[Aleksey Shipilev]

On Mon, 7 Dec 2020 11:19:09 GMT, Thomas Wuerthinger <github.com+5550412+thomaswue at openjdk.org> wrote:

> It is not an "implementation detail" if the change in semantics is visible to the user application. We are forced to implement this new feature in the GraalVM compiler or there will be unexpected observable differences in behaviour when executing the same Java application with the same command line flags.

The fact that `blackhole` is implemented as C1/C2 intrinsic *is* the implementation detail. It does not have to be, and it would not affect the externally usable `CompileCommand`. If Graal (or any other JIT compiler, for that matter) wants to hook into OpenJDK JIT compiler infrastructure, then I think it is reasonable to expect it reacts on compile commands in the similar manner.

> It is still a public API if it is a flag on the Java command line.

I think that redefines what public API is. JVM flags are not Java public API.
 
> What do you mean by "does not carry its weight"? Is the process to introduce a Java API too heavy-weight and therefore this solution was chosen?

Public Java API comes with the associated maintainability, reliability, security costs. Once you put the method into public Java API, there is (almost) no way back. If you have a bug in public Java API method, you have a problem. If that bug is a security one (e.g. crashing the JVM by 3rd party code), you have a huge problem. For the similar reasons, we have `-XX:CompileCommand=inline,*`, but `@ForceInline` is not a public API -- we can instruct compiler to do special thing, but that requires the explicit opt-in by those who control the JVM run.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1203