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

[Thomas Wuerthinger]

On Mon, 7 Dec 2020 10:59:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> That could set a dangerous precedent as it is otherwise a strongly assumed global invariant that the executing Java code has identical semantics independent of whether it is compiled or interpreted. It is also the first intrinsic that is dynamically configurable from the command line.
>> 
>> I do agree introducing a whitebox API recognized by the compiler for microbenchmarking is the right approach; and much better than the previous one trying to outsmart the compiler with some complex Java code. 
>> 
>> Why did you dismiss the option to add a blackhole method to the JDK?
>
>> That could set a dangerous precedent as it is otherwise a strongly assumed global invariant that the executing Java code has identical semantics independent of whether it is compiled or interpreted. It is also the first intrinsic that is dynamically configurable from the command line.
> 
> As I said above, `BreakAt` already changes the semantics. Compiler commands is a low-level API to instruct compiler to do something special. Here, we want compiler to do something special. `blackhole` being treated as intrinsic in VM code is the implementation detail. The previous incarnations of the patch were not doing it, and it was only done to simplify the internal compiler hooks.
>  
>> Why did you dismiss the option to add a blackhole method to the JDK?
> 
> Because in my mind, public Java API does not carry its weight here, for a single-purpose use in JMH.

It is not an "implementation detail" if the change in semantics is visible to the user application. We are 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.

It is still a public API if it is a flag on the Java command line.

What do you mean by "does not carry its weight"? Is the process to introduce a Java API too heavy-weight and therefore this solution was chosen?

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

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