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

Tobias Hartmann tobias.hartmann at oracle.com
Fri Mar 2 09:15:12 UTC 2018


On 02.03.2018 03:11, David Holmes wrote:
> It's not the scalarized object I'm concerned about but other actions that may happen after the
> allocation point and which would never have occurred if the allocation threw OOME. But perhaps such
> actions are not possible under the definition of "safe" for this transformation.

It depends on what kind of other actions that would be but it's clearly possible that the user would
see an OOME at an "unexpected" location in the code. For example:

MyObject o = new MyObject();
o.x = 42;
o.y = 43;
System.out.println(o.x);
myMethod(); // Deoptimize here for some reason
System.out.println(o.y);
return;

C2 could scalarize 'o' because EA determined that it does not escape and we would then need to
re-allocate once we deoptimize at the myMethod() call (because we will continue execution in the
interpreter and 'o' is still live). If this re-allocation fails, the user would see the printed "42"
followed by an OOME which is kind of unexpected at that point.

It's the same with VirtualMachineErrors or metaspace OOMEs during class loading (they might be
"unexpected" to the user as well). According to [1], OOMEs can basically be thrown at any point in
the program because "OutOfMemoryError may be thrown when an excessive amount of time is being spent
doing garbage collection and little memory is being freed" [1].

> But we should probably discuss this elsewhere.

Yes, the discussion is independent of this patch. Feel free to follow up by email or chat.

Can I assume you are okay with webrev.01?

Thanks,
Tobias

[1] https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/memleaks002.html


More information about the hotspot-dev mailing list