Hi Mandy, the OOME thrown for VM limits reasons is not related to any purported heap exhaustion but to the VM refusing to allocate an array of size Integer.MAX_VALUE or Integer.MAX_VALUE - 1, *even* if there's plenty of space. For example, with 8 GiB of heap and a size of Integer.MAX_VALUE - 2 the small program runs without fuss: java -XX:+UseG1GC -Xms8g -Xmx8g -cp ... Softly 2147483645 But when the argument is increased by 1 to Integer.MAX_VALUE - 1 java -XX:+UseG1GC -Xms8g -Xmx8g -cp ... Softly 2147483646 you immediately get: Exception in thread "main" java.lang.AssertionError: non-null referent at Softly.main(Softly.java:26) Caused by: java.lang.OutOfMemoryError: Requested array size exceeds VM limit at Softly.main(Softly.java:15) In other words, OOME is "abused" in such cases. A VM limit error should really throw another kind of error, not OOME, because contrary to its name there's not necessarily a lack of memory space, as shown here. To parallel current behavior, thus, the spec should be amended as proposed "... an OutOfMemoryError caused by Java heap space exhaustion." or a similar wording. Alternatively, to maintain the current spec untouched, the VM should throw another kind of error for VM limits. Not sure if this has any adverse impact on existing code in the wild. Greetings Raffaello On 2021-06-04 21:16, Mandy Chung wrote:

I'm not sure if the spec should be updated.  JDK-8267222 needs the GC team to evaluate.

I have added my comment in this JBS issue.

The SoftReference spec has the guarantee:    “All soft references to softly-reachable objects are guaranteed to have been cleared before the virtual machine throws an OutOfMemoryError.”

This is a reasonable guarantee expected by design in response to memory demand.

For the OOME thrown due to "requested array size exceeds VM limit", it seems that this is a fast-path throwing OOME without really going through the object allocation request (where reference processing will be performed in GC cycle).

The question to the GC team is whether VM implementation can and should support this soft reference guarantee. Note that the soft reference objects are cleared as specified, the large object allocation exceeding VM limit would fail any way. If the implementation is feasible, I'm inclined to clear the soft reference objects when OOME is thrown as specified even the object allocation request is known to fail.

Mandy

On 6/3/21 11:57 AM, Raffaello Giulietti wrote:

...

Hi,

upon reading [1] I tried a similar scenario, but where OOME are caused by "Java heap space" exhaustion rather than by VM limits.

import java.lang.ref.SoftReference; import java.text.DecimalFormat; import java.util.ArrayList;

public class Softly {

    public static void main(String[] args) {         var size = Integer.parseInt(args[0]);         var format = new DecimalFormat("#,###");         var news = 0;         var ref = new SoftReference<>(new ArrayList<>());         for (;;) {             byte[] b = null;             try {                 b = new byte[size];                 ++news;                 ref.get().add(b);             } catch (NullPointerException __) {                 System.out.format("totSize = %20s, allocations = %d\n", format.format((long) news * size), news);                 ref = new SoftReference<>(new ArrayList<>());                 ref.get().add(b);             } catch (OutOfMemoryError e) {                 if (ref.refersTo(null)) {                     throw new AssertionError("allocations = %d".formatted((news)), e);                 }                 throw new AssertionError("non-null referent", e);             }         }     }

}

E.g., java -XX:+UseG1GC -Xms1g -Xmx1g -cp ... Softly 800000000

Depending on the collector and how tight the heap is, I sometimes observe a "Java heap space" OOME but then the referent of ref is null. I never observed a OOME with a non-null referent for ref. Hence, in scenarios where OOME are caused by heap exhaustion, soft refs seem to work as advertised.

Tried on AdoptOpenJDK-16.0.1+9 with SerialGC, ParallelGC, G1GC, ZGC and ShenandoahGC with either -Xms1g/-Xmx1g or -Xms2g/-Xmx2g (small heaps) and various byte[] sizes.

Thus, the current wording in SoftReference's javadoc:

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

could be amended to read:

"All soft references to softly-reachable objects are guaranteed to have been cleared before the virtual machine throws an OutOfMemoryError caused by Java heap space exhaustion."

Greetings Raffaello

----

[1] https://bugs.openjdk.java.net/browse/JDK-8267222