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
----