RFR: 8331208: Memory stress test that checks OutOfMemoryError stack trace fails

[David Holmes]

On Tue, 30 Apr 2024 07:08:26 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/memAllocator.cpp line 127:
>> 
>>> 125:   const char* message = _overhead_limit_exceeded ? "GC overhead limit exceeded" : "Java heap space";
>>> 126:   // -XX:+HeapDumpOnOutOfMemoryError and -XX:OnOutOfMemoryError support
>>> 127:   report_java_out_of_memory(message);
>> 
>> Not obvious we now need this to be unconditional.
>
> I think it was a mistake to make it conditional when RetryableAllocationMark was first introduced. The purpose of RAM was to only to resolve a correctness issue wrt to JVMTI (it was seeing the "same" exception being reported twice). The -XX actions do not change the semantics of the exception throwing so can be done unconditionally.

But if this is a hidden/internal OOME then why would we treat it as a normal OOME and trigger the XX action? If the allocation routines returned null instead, we would never consider triggering the XX actions for OOME.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18925#discussion_r1586046804