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

[Doug Simon]

On Thu, 2 May 2024 01:24:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - don't perform XX actions for OOME when in scope of an InternalOOMEMark
>>  - rename SandboxedOOMEMark to InternalOOMEMark
>
> src/hotspot/share/gc/shared/memAllocator.hpp line 131:
> 
>> 129: 
>> 130:  public:
>> 131:   InternalOOMEMark(JavaThread* thread) {
> 
> Suggestion: add a comment:
> 
> // Passing a null thread allows for a no-op implementation for contexts that will suppress
> // throwing of the OOME - see RetryableAllocationMark.
> 
> I was wondering if we really need this. AFAICS it would be harmless to always pass in the current thread and set the thread's field because when we would have passed null then no exception would be thrown anyway. It seems the null thread is only used as a means for RAM to track whether activate was false. But I guess a no-op IOM achieves the same goal.

Throwing of the OOME is never suppressed by InternalOOMEMark. It only changes how the OOME is initialized.
When RetryableAllocationMark passes `thread == null`, it wants the normal OOME initialization to be done and JVMTI events to be fired.
In the context of https://bugs.openjdk.org/browse/JDK-8331429, I propose to leave this PR as is. That issue will remove `activate` altogether (cc @mur47x111 ).

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

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