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

Vladimir Ivanov vlivanov at openjdk.java.net
Mon Dec 7 15:45:19 UTC 2020


On Mon, 7 Dec 2020 12:22:35 GMT, Aleksey Shipilev <shade 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.
>> 
>> 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".
>
>> 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.

As an afterthought, I would file a CSR request for this change (though CompileCommand has diagnostic nature, it is a product flag after all). If it turns out it's not an appropriate addition, a separate diagnostic/experimental flag can be added instead. (Though that would be unfortunate.) 

If possible change in behavior is a real concern, the implementation can be changed to affect only effect-free methods (e.g., applied only to empty methods). 

The upside of exposing the functionality as a command-line option (diagnostic or experimental, but even product) is it has much lower level of commitment associated with it. If there's enough motivation/justification to graduate it into public Java API, it can be done later when there's enough confidence that it's the right fit there.

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

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


More information about the hotspot-dev mailing list