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

[Volker Simonis]

On Thu, 25 Nov 2021 09:45:56 GMT, Christian Hagedorn <chagedorn 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.
>
> test/hotspot/jtreg/compiler/exceptions/OptimizeImplicitExceptions.java line 166:
> 
>> 164:     // Checks after the JIT-compiled test method has been invoked 'PerBytecodeTrapLimit' times.
>> 165:     private static void checkTwo(TestMode testMode, ImplicitException impExcp, Exception ex, Method throwImplicitException_m, int invocations) {
>> 166: 
> 
> If I see that correctly, `checkTwo`, `checkThree` and `checkFour` only differ in whether using `PerBytecodeTrapLimit` or `Tier0InvokeNotifyFreq` and could be merged together (if the omitted assertions in `checkThree` and `checkFour` for the exception message compared to `checkTwo` are valid to be added again).

That's a good point, now that the tests have got a little simpler :)

I'll have to add more cases for JDK-8273563 but I think it's just fair to leave it for that change.

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

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