RFR: 8273563: Improve performance of implicit exceptions with -XX:-OmitStackTraceInFastThrow [v11]

[Oli Gillespie]

On Thu, 2 Dec 2021 00:25:18 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Volker Simonis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Fix jit/t/t105/t105.java to also use -XX:-OptimizeImplicitExceptions in addition to -XX:-OmitStacktracesInFastThrow
>>  - Fix IR Framework test Traps::classCheck() which now behaves differently with -XX:+OptimizeImplicitExceptions
>>  - Added jtreg test and extended the Whitebox API to export decompile, deopt and trap counters
>>    Rebased on top of '8275908: Record null_check traps for calls and array_check traps in the interpreter'
>>  - Fix special case where we're creating an implicit exception for a regular invoke* bytecode
>>  - Minor updates as requested by @TheRealMDoerr
>>  - 8273563: Improve performance of implicit exceptions with -XX:-OmitStackTraceInFastThrow
>
> src/hotspot/share/opto/graphKit.cpp line 627:
> 
>> 625:       const TypeKlassPtr *ex_type = TypeKlassPtr::make(ex_ciInstKlass);
>> 626:       kill_dead_locals();
>> 627:       Node* ex_node = new_instance(makecon(ex_type), NULL, NULL, true);
> 
> What happened if deoptimization happen during this allocation (which is safepoint)?
> Which bytecode will be executed in Interpeter after deopt?

I picked up this PR to try to revive it. I believe there is a bug here like you suspected.

Here's my reproducer: https://gist.github.com/olivergillespie/6e8c93c8367ac2ba060e339450581c5f

It fails reliably (moreso with fastdebug):


java.lang.AssertionError: BUG: Swallowed exceptions. NPEs: 17, AIOOBs: 32, getfield NPES: 0.


Bytecodes which [should_reexeute](https://github.com/openjdk/jdk/blob/486ff5d3fcfa924ebcb0ce92c067a02b8f9a2ebd/src/hotspot/share/interpreter/abstractInterpreter.cpp#L438) (like `getfield`) are okay, but others like `aaload` are not. Deopt at this point means we don't throw the exception, and the bytecode is not reexecuted in the interpreter.

I'm not sure how to fix it, I'm looking into it this week but if you have any ideas please let me know.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/5488#discussion_r2812551147