<div dir="ltr"><div><div><div>Re-posting the original link <a href="https://github.com/adoptium/adoptium-support/issues/1096">https://github.com/adoptium/adoptium-support/issues/1096</a> (as it seems like the mail.openjdk mangled the semi-colon, at least from the archives view).<br><br></div>Is this an OpenJDK bug?<br><br>If so, would somebody with permissions elevate this to <a href="https://bugs.openjdk.org">https://bugs.openjdk.org</a>?<br><br>If it's not a bug, I'm hoping to gain some clarity on SoftReference / OOME guarantees.<br><br></div>I'm happy to provide additional assistance if needed.<br><br></div><div>Thanks,</div><div>-Devin<br></div><div><div><br><div><br><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 23, 2024 at 1:21 PM Devin Smith <<a href="mailto:devinsmith@deephaven.io">devinsmith@deephaven.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><div><div><div><span style="font-family:arial,sans-serif">Hi,<br><br></span></div><span style="font-family:arial,sans-serif">This is in reference to an issue I posted on <a href="https://github.com/adoptium/adoptium-support/issues/1096" target="_blank">https://github.com/adoptium/adoptium-support/issues/1096</a>; it was suggested I post to this list.<br><br></span></div><span style="font-family:arial,sans-serif">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`).<br><br>```<br></span><pre><span style="font-family:arial,sans-serif"><code>[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)<br>```<br></code></span></pre><span style="font-family:arial,sans-serif"><br></span></div><span style="font-family:arial,sans-serif">This behavior seems to go against one of the core tenants of memory management / SoftReference docs:<br><br>> All soft references to softly-reachable objects are guaranteed to have 
been cleared before the virtual machine throws an OutOfMemoryError<br><br></span></div><span style="font-family:arial,sans-serif">I'm able to reproduce this across all LTS versions with a variety of GC collectors; it appears that ZGC and Shenandoah do <em>not</em> exhibit this behavior. Possibly b/c ZGC has already fixed this bug <a href="https://bugs.openjdk.org/browse/JDK-8289838" target="_blank">https://bugs.openjdk.org/browse/JDK-8289838</a> (there are a number of OpenJDK issues with similar titles).<br></span><div><div><span style="font-family:arial,sans-serif"><br><a href="https://github.com/devinrsmith/GCLockerTooOftenAllocating" target="_blank">https://github.com/devinrsmith/GCLockerTooOftenAllocating</a> provides the example code necessary to reproduce.<br><br></span></div>Thanks,</div><div>-Devin<div></div><div><br><br></div></div></div></div>
</blockquote></div>