DirectBufferAllocTest fails after replacement of Thread.sleep() with Thread.onSpinWait()

[Сергей Цыпанов]

> Do you get the OOME using Thread.yield() or just a busy-wait?

I reproduce it with busy-wait involving Thread.onSpinWait() and only when the test is run with -XX:MaxDirectMemorySize=128m -XX:-ExplicitGCInvokesConcurrent

If I either drop mentioned VM options or use Thread.sleep() OOME will never happen (at least on my machine).

P.S. If I use Thread.yield() the problem is not reproduced any more.

P.P.S. How should I interpret this? Thread.onSpinWait() is discouraged for busy-waiting?

> On 20/06/2022 7:43 pm, Сергей Цыпанов wrote:
> 
>> Hello,
>>
>> while playing with Thread.onSpinWait() in busy-wait loops I've replaced Thread.sleep() with
>> preferable (at least as it appears from the JavaDoc) Thread.onSpinWait() in java.nio.Bits.
>>
>> Immediately after that DirectBufferAllocTest started to fail with OOME. This is surprising, as the change
>> does not seem to change any program logic:
> 
> Do you get the OOME using Thread.yield() or just a busy-wait? The sleep
> limits the computation and ensures other threads can make progress;
> whereas a busy loop may not allow that and so you exhaust memory.
> 
> David
> 
>> diff --git a/src/java.base/share/classes/java/nio/Bits.java b/src/java.base/share/classes/java/nio/Bits.java
>> --- a/src/java.base/share/classes/java/nio/Bits.java (revision 7d4df6a83f6333e0e73686b807ee5d4b0ac10cd2)
>> +++ b/src/java.base/share/classes/java/nio/Bits.java (date 1655709575452)
>> @@ -162,8 +162,7 @@
>> }
>> try {
>> if (!jlra.waitForReferenceProcessing()) {
>> - Thread.sleep(sleepTime);
>> - sleepTime <<= 1;
>> + Thread.onSpinWait();
>> sleeps++;
>> }
>> } catch (InterruptedException e) {
>>
>> Another surprise here is that when I copy the test as simple Java application
>> it fails when I run it with the same JVM options (-XX:MaxDirectMemorySize=128m -XX:-ExplicitGCInvokesConcurrent),
>> but doesn't if I put a breakpoint in IntelliJ at sleeps++ and stop there for 6-7 times while
>> the test is running. No failure observed if I drop JVM options either.
>>
>> Is it a bug somewhere in GC/runtime or am I doing something wrong?
>>
>> Regards,
>> Sergey Tsypanov