RFR: 8267532: Try/catch block not optimized as expected [v4]

[Jorn Vernee]

On Mon, 6 Nov 2023 16:56:38 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> If the expectation is that unhandled exception entry points will be deopts, then you may not actually have to do anything since the exception handling would end up going through the interpreter.  Or maybe Deoptimization::uncommon_trap_inner could be augmented to update the MDO at the right point?
>
> Thinking more about this: marking the handler as entered is mostly useful for C2 so that when we deoptimize and compile in C2 again, we don't emit an uncommon trap again. However, that would also require not seeing any exception in the interpreter or in tier 1-3. (Maybe not tracking C2 handler enters is actually desirable).
> 
> I think we can mark the handler as entered in the deoptimization code that handles the uncommon trap that replaces the ex. handler instead, for C2 (and maybe that also works for JVMCI?)
> 
> P.S. Ah, I didn't see your last comment :-)

> If the expectation is that unhandled exception entry points will be deopts, then you may not actually have to do anything since the exception handling would end up going through the interpreter.

The uncommon trap is located in the exception handler itself, so after the deopt we start interpreting in the exception handler, and don't go through the interpreter's exception dispatch code where we do the profiling (`InterpreterRuntime::exception_handler_for_exception`).

I think handling this in `Deoptimization::uncommon_trap_inner` can work though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16416#discussion_r1383671561