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

[Jorn Vernee]

On Mon, 6 Nov 2023 16:39:08 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> Hmm, you're right. The current code doesn't seem to work for exceptions thrown in an inlinee and caught in a caller.
>> 
>> I thought we only saw `-1` when we had to unwind a frame, and then we'd do the exception handler lookup again. But, looking now, there doesn't seem to be a following lookup.
>> 
>> I'll dig into this some more.
>
> 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 :-)

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

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