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

[David Holmes]

Hi Tobias,

On 1/03/2018 7:32 PM, 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.

Interesting - does that mean you have to roll back everything that 
happened since the allocation point ???

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

Looks okay. My only thought is whether the PEM should be across the full 
scope of the VerifyStack logic (as you have it) or whether it should 
only wrap the code you know has the ExceptionMark? I guess as this is a 
JRT_LEAF function we don't expect anything else to generate exceptions, 
so the placement shouldn't really matter.

Thanks,
David

> Thanks,
> Tobias
>