[11] RFR(XS): 8198826: -XX:+VerifyStack fails with fatal error: ExceptionMark constructor expects no pending exceptions

[Tobias Hartmann]

Hi David,

thanks for looking at this!

On 28.02.2018 22:53, David Holmes wrote:
> Once an exception is pending code has to be very careful about how it proceeds - both in terms of
> "the previous action failed so what do I do now?" and "I've got a pending exception so need to be
> very careful about what I call".
> 
> I'm not familiar with this code at all and looking at it it is very hard for me to understand
> exactly what the occurrence of the OOME means for the rest of the code. Normally I would expect to
> see code "bail out" as soon as possible, while this code seems to continue to do lots of (presumably
> necessary) things.

In this case, C2 did aggressive scalarization based on escape analysis to remove an object
allocation in compiled code. When deoptimizing, we need to restore the interpreter state including
re-allocating that scalarized object (because the interpreter does not support scalarization).

If re-allocation fails due to an OOME, we still need to continue restoring the interpreter state
(while propagating that exception to be later thrown by the interpreter). So we cannot just simply
bail out but need to make sure that the following code works fine with a pending exception.

> My concern with this simple fix is that if the occurrence of the OOME has actually resulted in
> breakage, then skipping the VerifyStack logic may be skipping the code that would detect that
> breakage. In which case it may be better to save and clear the exception and restore it afterwards.

Yes, that's also what Vladimir suggested in the bug comments. Here's a new webrev that saves and
restores the pending oop while still executing the stack verification code:
http://cr.openjdk.java.net/~thartmann/8198826/webrev.01/

Thanks,
Tobias