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

[Aleksey Shipilev]

On Mon, 7 Dec 2020 12:03:05 GMT, Thomas Wuerthinger <github.com+5550412+thomaswue at openjdk.org> wrote:

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

`BreakAt` compile command *also* changes the semantics of the Java program.

Speaking of Graal, I see that it [already intrinsifies](https://github.com/oracle/graal/blob/744654c108178d531c99fc802f451b55b72a48c9/compiler/src/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/StandardGraphBuilderPlugins.java#L1492) JMH `Blackhole` methods directly. I cannot see how escapes your argument: compiler changes the semantics by effectively removing the content of a method. And it does so without user explicitly asking for it?

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

I think you severely underestimate the costs of going that way. LOC count has little to do with the costs here. I have been on that road before, and that is why I believe it does not worth it ("does not carry its weight"), when there is a way to get what JMH wants with the VM-specific compile commands. You are welcome to try proposing the public APIs for this.

I can retract the `-XX:CompileCommand` addition and intrinsify JMH methods directly, like Graal does. But I think that would be less nice, as it makes JDK aware about non-JDK code, and forces JMH to stick with the current `Blackhole` Java signatures.

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

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