RFR: 8275908: Record null_check traps for calls and array_check traps in the interpreter [v3]

[David Holmes]

On Fri, 26 Nov 2021 11:13:29 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> `null_checks` occurring at invoke bytecodes are currently not recorded by the profiler. This leads to unnecessary uncommon traps, deoptimizations and recompilations for exceptions which already occurred before the compilation (i.e. are "hot"). This change fixes the problem in the interpreter.
>> 
>> `array_checks` are currently recorded as `class_checks` in the interpreter and therefore not recognized by the compiler. This again leads to uncommon traps, deoptimizations and recompilations. This change unifies the handling of `array_checks` in the interpreter and compiler and prevents unnecessary recompilation.
>> 
>> The test is a stripped down version of a test which was developed for [JDK-8273563: Improve performance of implicit exceptions with -XX:-OmitStackTraceInFastThrow](https://bugs.openjdk.java.net/browse/JDK-8273563) (still [under review](https://github.com/openjdk/jdk/pull/5488)). It introduces an extension to the Whitebox API to expose the decompile, deopt and trap counters which is also required for testing [JDK-8273563](https://bugs.openjdk.java.net/browse/JDK-8273563). I think (and hope) it will also be helpful for others in the future.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Decompile.java test for non-JVMCI builds

The new tests are not written correctly and are causing failures in our tier3 CI runs.

If you set an explicit GC on the @run line then you have to ensure no GC option is passed in when running jtreg, else you get two GC's requested and the test fails to run.

https://bugs.openjdk.java.net/browse/JDK-8277878

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

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