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

[Volker Simonis]

On Tue, 8 Dec 2020 10:38:23 GMT, Thomas Wuerthinger <github.com+5550412+thomaswue at openjdk.org> wrote:

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

I've just realized that apparently, after this PR was closed, comments on the PR were still forwarded to the corresponding mailing list thread whereas answers on the mailing list thread were not appended to this PR any more. If you want to enjoy the full conversation please have a look at the [hotspot-dev mailing list archive](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-December/).

PS: I've also opened [ SKARA-843: Mails are not forwarded to a closed PR any more](https://bugs.openjdk.java.net/browse/SKARA-843) for the Skara team to check this behaviour.

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

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