RFR: 8345266: java/util/concurrent/locks/StampedLock/OOMEInStampedLock.java JTREG_TEST_THREAD_FACTORY=Virtual fails with OOME

[Patricio Chilano Mateo]

On Tue, 17 Dec 2024 02:11:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Is OOME the only possible exception in this code path?
>
Yes. The freeze code can also throw SOE but only when unmounting from Java, i.e we already filter the preempt case.

> src/hotspot/share/runtime/continuation.cpp line 164:
> 
>> 162:   JVMTI_ONLY(jubm.set_result(res);)
>> 163: 
>> 164:   if (target->has_pending_exception()) {
> 
> Is `target` always the current thread, because we should only ever check and clear exceptions on the current thread. ??

Yes. For context, this method was copied from the external preemption work which implemented the `Continuation.tryPreempt` API, where a thread tries to preempt another one. But that was all experimental and currently target is always current. I could rename the instances to avoid confusion.

> test/jdk/java/lang/Thread/virtual/MonitorOOM.java line 66:
> 
>> 64:                         if (testWait) {
>> 65:                             lock.wait(5);
>> 66:                         }
> 
> If you have filled the heap won't you always get the OOME on the monitor enter?

Yes, both monitor enter and later Object.wait will fail to unmount due to OOM, so we will just pin to the carrier.

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

PR Comment: https://git.openjdk.org/jdk/pull/22780#issuecomment-2547470798
PR Review Comment: https://git.openjdk.org/jdk/pull/22780#discussion_r1887872019
PR Review Comment: https://git.openjdk.org/jdk/pull/22780#discussion_r1887872426