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

[Roland Westrelin]

On Thu, 2 Dec 2021 05:17:29 GMT, Dean Long <dlong at openjdk.org> wrote:

>     1. a runtime call to the rethrow stub.  The comment says "must not deoptimize", but I'm not sure what prevents that

That one is a leaf call and doesn't capture debug info so I think it's safe to assume it can't deoptimize.

>     2. catch_call_exceptions(), which does an uncommon trap for unloaded exception classes

There's a push_ex_oop() right because the uncommon trap and that one clears the stack so it can't be the reason to preserve the stack.

> > 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?

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.

So you agree that if there's no handler then there's no need to preserve the stack?

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

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