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

[David Holmes]

On 2/03/2018 7:15 PM, Tobias Hartmann wrote:
> 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].

Hmmm to me that violates the precise exceptions requirement of the language.

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

Yes - thanks.

David

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