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

[Vladimir Kozlov]

Looks nice.

Thanks,
Vladimir

On 3/1/18 1:32 AM, Tobias Hartmann wrote:
> 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
>