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

[Doug Simon]

This pull request mitigates failures in memory stress tests that check the stack trace of an `OutOfMemoryError` for certain expected entries.

The stack trace of an OOME will [not be allocated once all preallocated OOMEs are used up](https://github.com/openjdk/jdk/blob/3d5eeac3a38ece4a23ea6da2dfe5939d64e81cea/src/hotspot/share/memory/universe.cpp#L722). If the only heap allocations performed in stressful conditions are those of the stress test, then the [4 preallocated OOMEs](https://github.com/openjdk/jdk/blob/f1d0e715b67e2ca47b525069d8153abbb33f75b9/src/hotspot/share/runtime/globals.hpp#L800) would be sufficient. However, it's possible for VM internal allocations to also occur during stressful conditions, especially in `-Xcomp` mode. For example, [CompileBroker::compile_method](https://github.com/openjdk/jdk/blob/3d5eeac3a38ece4a23ea6da2dfe5939d64e81cea/src/hotspot/share/compiler/compileBroker.cpp#L1399) will try to resolve the string constants in the constant pool of the method about to be compiled. This can fail as shown here:

V  [jvm.dll+0x62c23a]  Exceptions::_throw+0x11a  (exceptions.cpp:168)
V  [jvm.dll+0x62d85b]  Exceptions::_throw_oop+0xab  (exceptions.cpp:140)
V  [jvm.dll+0xbbce78]  MemAllocator::Allocation::check_out_of_memory+0x208  (memAllocator.cpp:138)
V  [jvm.dll+0xbbcac8]  MemAllocator::allocate+0x158  (memAllocator.cpp:377)
V  [jvm.dll+0x79bd05]  InstanceKlass::allocate_instance+0x95  (instanceKlass.cpp:1509)
V  [jvm.dll+0x7ddeed]  java_lang_String::basic_create+0x9d  (javaClasses.cpp:273)
V  [jvm.dll+0x7e43c0]  java_lang_String::create_from_unicode+0x60  (javaClasses.cpp:291)
V  [jvm.dll+0xdb91a5]  StringTable::do_intern+0xb5  (stringTable.cpp:379)
V  [jvm.dll+0xdba9f2]  StringTable::intern+0x1b2  (stringTable.cpp:368)
V  [jvm.dll+0xdbaaa6]  StringTable::intern+0x86  (stringTable.cpp:328)
V  [jvm.dll+0x51c8b1]  ConstantPool::string_at_impl+0x1d1  (constantPool.cpp:1251)
V  [jvm.dll+0x51b95b]  ConstantPool::resolve_string_constants_impl+0xeb  (constantPool.cpp:800)
V  [jvm.dll+0x4f2f8d]  CompileBroker::compile_method+0x31d  (compileBroker.cpp:1395)
V  [jvm.dll+0x4f3474]  CompileBroker::compile_method+0xc4  (compileBroker.cpp:1348)

These internal allocations can occur before the allocations of the test and thus use up the pre-allocated OOMEs. As a result, the OOMEs triggered by the stress test may end up throwing the [default, shared OOME instance](https://github.com/openjdk/jdk/blob/3d5eeac3a38ece4a23ea6da2dfe5939d64e81cea/src/hotspot/share/memory/universe.cpp#L722) that have no stack trace.

This PR mitigates this by introducing a scope (see [`SandboxedOOMEMark`](https://github.com/openjdk/jdk/pull/18925/files#diff-8656914dbf640348409a4acb38eb0cc179a93a74d049d4fe62d79d252d13cdacR124)) in which a failed heap allocation results in the shared, stacktrace-less OOME instance being thrown. This scope is used for guarding VM internal allocations where an OOME will not be propagated to user code. In addition, JVMTI "resource exhausted" events are disabled in the scope of an `SandboxedOOMEMark`.

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

Commit messages:
 - unconditionally disable JVMTI resource exhausted events in scope of a SandboxedOOMEMark
 - only support disabling JVMTI events in SandboxedOOMEMark scope
 - generalized RetryableAllocationMark to SandboxedOOMEMark

Changes: https://git.openjdk.org/jdk/pull/18925/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18925&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331208
  Stats: 113 lines in 11 files changed: 54 ins; 40 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/18925.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18925/head:pull/18925

PR: https://git.openjdk.org/jdk/pull/18925