From devinsmith at deephaven.io  Thu May 23 20:21:55 2024
From: devinsmith at deephaven.io (Devin Smith)
Date: Thu, 23 May 2024 13:21:55 -0700
Subject: SoftReferences not cleared before OOME
Message-ID: <CAAcX=h3pHi5JmVx2nc+VGyBmQ=cYZteTQTKG5vKcmHg-gbNbjA@mail.gmail.com>

Hi,

This is in reference to an issue I posted on
https://github.com/adoptium/adoptium-support/issues/1096; it was suggested
I post to this list.

I'm able to reliably reproduce an issue whereby the JVM throws an
OutOfMemoryException where the majority of heap space is reclaimable soft
references. This can be verified with `-XX:+HeapDumpOnOutOfMemoryError` and
analyzing the resulting dump in VisualVM (or other heap dump tools). The
condition is triggered by also having concurrent computation inside JNI
critical regions (subject to multiple attempts wrt
`-XX:GCLockerRetryAllocationCount`).

```

[1.242s][warning][gc,alloc] main: Retried waiting for GCLocker too
often allocating 524290 words
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
        at java.base/java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:71)
        at java.base/java.nio.ByteBuffer.allocate(ByteBuffer.java:391)
        at io.deephaven.example.GCLockerTooOftenAllocating.main(GCLockerTooOftenAllocating.java:45)
```


This behavior seems to go against one of the core tenants of memory
management / SoftReference docs:

> All soft references to softly-reachable objects are guaranteed to have
been cleared before the virtual machine throws an OutOfMemoryError

I'm able to reproduce this across all LTS versions with a variety of GC
collectors; it appears that ZGC and Shenandoah do *not* exhibit this
behavior. Possibly b/c ZGC has already fixed this bug
https://bugs.openjdk.org/browse/JDK-8289838 (there are a number of OpenJDK
issues with similar titles).

https://github.com/devinrsmith/GCLockerTooOftenAllocating provides the
example code necessary to reproduce.

Thanks,
-Devin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-use/attachments/20240523/4bbe23cb/attachment.htm>

From devinsmith at deephaven.io  Wed May 29 17:57:51 2024
From: devinsmith at deephaven.io (Devin Smith)
Date: Wed, 29 May 2024 10:57:51 -0700
Subject: SoftReferences not cleared before OOME
In-Reply-To: <CAAcX=h3pHi5JmVx2nc+VGyBmQ=cYZteTQTKG5vKcmHg-gbNbjA@mail.gmail.com>
References: <CAAcX=h3pHi5JmVx2nc+VGyBmQ=cYZteTQTKG5vKcmHg-gbNbjA@mail.gmail.com>
Message-ID: <CAAcX=h1F59m2ZbpsdTs_f=wATx67_bENiA-mA74uvY2CMnQ4sA@mail.gmail.com>

Re-posting the original link
https://github.com/adoptium/adoptium-support/issues/1096 (as it seems like
the mail.openjdk mangled the semi-colon, at least from the archives view).

Is this an OpenJDK bug?

If so, would somebody with permissions elevate this to
https://bugs.openjdk.org?

If it's not a bug, I'm hoping to gain some clarity on SoftReference / OOME
guarantees.

I'm happy to provide additional assistance if needed.

Thanks,
-Devin




On Thu, May 23, 2024 at 1:21?PM Devin Smith <devinsmith at deephaven.io> wrote:

> Hi,
>
> This is in reference to an issue I posted on
> https://github.com/adoptium/adoptium-support/issues/1096; it was
> suggested I post to this list.
>
> I'm able to reliably reproduce an issue whereby the JVM throws an
> OutOfMemoryException where the majority of heap space is reclaimable soft
> references. This can be verified with `-XX:+HeapDumpOnOutOfMemoryError` and
> analyzing the resulting dump in VisualVM (or other heap dump tools). The
> condition is triggered by also having concurrent computation inside JNI
> critical regions (subject to multiple attempts wrt
> `-XX:GCLockerRetryAllocationCount`).
>
> ```
>
> [1.242s][warning][gc,alloc] main: Retried waiting for GCLocker too often allocating 524290 words
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>         at java.base/java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:71)
>         at java.base/java.nio.ByteBuffer.allocate(ByteBuffer.java:391)
>         at io.deephaven.example.GCLockerTooOftenAllocating.main(GCLockerTooOftenAllocating.java:45)
> ```
>
>
> This behavior seems to go against one of the core tenants of memory
> management / SoftReference docs:
>
> > All soft references to softly-reachable objects are guaranteed to have
> been cleared before the virtual machine throws an OutOfMemoryError
>
> I'm able to reproduce this across all LTS versions with a variety of GC
> collectors; it appears that ZGC and Shenandoah do *not* exhibit this
> behavior. Possibly b/c ZGC has already fixed this bug
> https://bugs.openjdk.org/browse/JDK-8289838 (there are a number of
> OpenJDK issues with similar titles).
>
> https://github.com/devinrsmith/GCLockerTooOftenAllocating provides the
> example code necessary to reproduce.
>
> Thanks,
> -Devin
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-use/attachments/20240529/53868db9/attachment-0001.htm>