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

[Roland Westrelin]

On Tue, 30 Nov 2021 18:49:17 GMT, Dean Long <dlong at openjdk.org> wrote:

> Out of curiosity, I checked when the "Keep its stack, for now" comment was added, and it was for JDK-4432078. The comment in the bug says:
> 
> "Missing stack contents in graphkit-based exceptions make it impossible to re-run the trapping bytecode in the interpreter. Fix is to retain stack information a little longer."

Thanks for investigating that further.
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?

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.

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.

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

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