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

[Thomas Wuerthinger]

On Mon, 7 Dec 2020 15:41:26 GMT, Volker Simonis <simonis at openjdk.org> wrote:

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

@simonis As one of the many OpenJDK downstream projects, GraalVM inherits by default all code and flags. We add one additional JIT compiler option and test thoroughly that there are zero observable differences other than performance when that option is enabled (which is the default in the GraalVM distribution). 

> I don't think the OpenJDK project has a responsibility to justify its implementation details to other projects which try to emulate its behaviour.

My understanding as a member of the OpenJDK community was that a GitHub PR like this is the appropriate place to engage in collaborative discussions. Let me know if this kind of engagement is undesirable.

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

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