RFR: 8276453: Undefined behavior in C1 LIR_OprDesc causes SEGV in fastdebug build [v5]

[Vladimir Kozlov]

On Wed, 10 Nov 2021 23:47:14 GMT, Man Cao <manc at openjdk.org> wrote:

> I uploaded benchmark results to https://bugs.openjdk.java.net/browse/JDK-8276453. It is over 20 trials. There is no observable difference. The most relevant metric is "Total Time in Compilation", which is the value of the hsperfdata counter java.ci.totalTime. It includes time spent in both C1 and C2. Let me know if you also need the logs from +LogCompilation. I have them but they are extremely large (900MiB after 7zip for 20 trials).
> 
> I'll work on changing LIR_Opr() to LIR_Opr::nullOpr() and splitting it up, as it also makes sense that the smaller patch should be backported to JDK 11 and 17.

Thank you for collecting perf data. Yes, `java.ci.totalTime` is good indicator. I don't know how you run but to get only C1 times and more or less accurate time you need to run with `-XX:TieredStopAtLevel=3 -XX:CICompilerCount=1` flags.

I was thinking about using LogCompilation tool to get C1 only times from logs (https://github.com/openjdk/jdk/tree/master/src/utils/LogCompilation)

$ java -XX:+LogCompilation -XX:TieredStopAtLevel=3 -XX:CICompilerCount=1 ...
$ java -jar logc.jar -S hotspot_pid609766.log | tail -15

NMethods: 1230 created 1230 live 4175704 bytes (4175704 peak) in the code cache
Phase times:
               setup 0.0020 0
           parse_hir 0.4560 0
     optimize_blocks 0.2910 0
                 gvn 0.0170 0
rangeCheckElimination 0.0820 0
optimize_null_checks 0.0060 0
             buildIR 0.9750 0
       lirGeneration 0.0360 0
          linearScan 0.3110 0
            emit_lir 0.3620 0
            codeemit 0.0810 0
         codeinstall 0.0530 0
               total 1.8720


But it is not accurate as `java.ci.totalTime`

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

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