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

[Volker Simonis]

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

>> 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.
>
>> 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).
> 
> Yes, applying it only to effect-free methods would be perfect. For such methods it is indeed comparable with the other compiler commands.

This change would have definitely required a CSR as described in [Hotspot Command-line Flags: Kinds, Lifecycle and the CSR Process](https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process).

Besides that, I don't understand @thomaswue argumentation that he's  "*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*". `-XX:` options are definitely an implementation detail of OpenJDK and as such not related to the Java SE specification in any way. The fact that the `-XX:` options are sub-devided into *product*, *diagnostic* and *experimental* options is again specific to the OpenJDK project and only denotes the level of support these options get within the project and not their relation to the Java SE specification.

Misusing the new new option will already have unpredictable effects in OpenJDK itself and make it behave "Java SE" incompatible. I don't think there's a requirement that all configurations (i.e. all combinations of command line options) of a "Java SE" implementation have to be "Java SE" compatible and this is especially true for extended options like `-XX:`. And by  the way, in addition to the `BreakAt*` command mentioned before, we already have other such options like for example `-XX:AbortVMOnException=` and `-XX:AbortVMOnExceptionMessage=` which make the OpenJDK behave non-Java SE compatible (not sure if you've implemented these in GraalVM in order to fully emulate OpenJDK :)

As far as I can see, a CSR ([JDK-8257827](https://bugs.openjdk.java.net/browse/JDK-8257827)) for this issue has already been created, which is good. Details like declaring this new option *product*, *experimental* or *diagnostic* should be discussed in the CSR, but in the end I don't think the OpenJDK project has a responsibility to justify its implementation details to other projects which try to emulate its behaviour.

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

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