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

[Thomas Wuerthinger]

On Mon, 7 Dec 2020 11:37:36 GMT, Aleksey Shipilev <shade 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.
>> 
>> It is still a public API if it is a flag on the Java command line.
>> 
>> 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?
>
>> 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.

There are similar expectations for backwards compatibility and ongoing maintenance of command line flags (except the ones marked explicitly as "experimental"). There is certainly also an expectation that flags are not creating new security vulnerabilities.

Whether a compiler inlines a method or not is not observable other than performance differences. This new command however can change the semantics of the Java program in unexpected ways by effectively removing the content of a method. The "inline" compile command and this new "blackhole" compile command are therefore not comparable.

I think introducing a blackhole method in the JDK would be the right thing to do instead of short-cutting the process. Maintaining such a method would also be trivial as it is only a few lines of code. Even an empty method would be OK. The method becomes part of the API; the intrinsification is part of the "implementation detail".

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

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