RFR: 8275638: GraphKit::combine_exception_states fails with "matching stack sizes" assert [v2]

[Dean Long]

On Wed, 1 Dec 2021 13:11:00 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>  Where would deoptimization occur then? In Parse::catch_inline_exceptions() when the right exception handlers is picked with subtype checks? I don't see any uncommon trap there. Maybe the requirement to keep the stack is no longer necessary?

At the end of the method I see:
1. a runtime call to the rethrow stub.  The comment says "must not deoptimize", but I'm not sure what prevents that
2. catch_call_exceptions(), which does an uncommon trap for unloaded exception classes

> The reason I didn't go with Vladimir's work around for 8273165 is that I think it could have a performance impact that would be more likely to be noticed than in the case of 8273165 (because late inlining of method handle has been around for many releases and is likely something that's relied on). We could extend Vladimir's work around by checking that the receiver may be null and that the null check would cause the exception to be thrown rather than deoptimization.

But with possible performance impact, right?

> Another way to deal with this could be to pop the stack if the current method has no exception handlers because then the exception is passed on to the caller and the entire frame is popped anyway. That would work nicely for this case as AFAIU, the method handle invoker can only be inlined from a lambda form that wouldn't have exception handlers.

That sounds promising.

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

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