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

[Tom Rodriguez]

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

>> src/hotspot/share/runtime/sharedRuntime.cpp line 784:
>> 
>>> 782: 
>>> 783:   if (handler_bci != -1) { // did we find a handler in this method?
>>> 784:     sd->method()->set_ex_handler_entered(handler_bci); // profile
>> 
>> Are you sure this handles inlined exception handlers properly for c2?  My recollection is that C2 generates single level tables and performs the inlined exception dispatch in the generated code.  If you notice the flag top_frame_only stops the walk through the callers and OptoRuntime::handle_exception_C always passes true for top_frame_only.  So it seems like sd will always be the ScopeDesc of the top frame.
>
> 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?

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

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