RFR(XS): 8198826: -XX:+VerifyStack fails with fatal error: ExceptionMark constructor expects no pending exceptions
david.holmes at oracle.com
Fri Mar 2 09:35:14 UTC 2018
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;
> myMethod(); // Deoptimize here for some reason
> 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 , 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" .
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.
>  https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/memleaks002.html
More information about the hotspot-dev