RFR(XS): 8198826: -XX:+VerifyStack fails with fatal error: ExceptionMark constructor expects no pending exceptions
david.holmes at oracle.com
Thu Mar 1 11:53:37 UTC 2018
On 1/03/2018 8:38 PM, Tobias Hartmann wrote:
> Hi David,
> On 01.03.2018 11:11, David Holmes wrote:
>> Interesting - does that mean you have to roll back everything that happened since the allocation
>> point ???
> No, besides the general JVM state, C2 compiled code also keeps track of the state of scalarized
> objects to be able to reconstruct them at safepoints, i.e., when deoptimization could happen (see
But if the allocation fails you don't have the ability to reconstruct
the object ?? The OOME must appear to happen at the point at which the
object should have been allocated, and nothing that happens after that
point can be seen to have happened.
>> 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.
> The ExceptionMark is in OopMapCache::compute_one_oop_map() which is called from two locations in the
> VerifyStack scope. A more narrow scope would be inside the for-loop and I think we would like to
> avoid that. And yes, we don't expect anything else to generate an exception (the PEM actually guards
> against that).
More information about the hotspot-dev