SoftReferences not cleared before OOME

[Thomas Schatzl]

Hi,

On 12.06.24 16:10, Devin Smith wrote:
> Thank you for following up; it does seem like this is a special case
> of https://bugs.openjdk.org/browse/JDK-8192647 . The only
> differentiating factor IMO is that we (/I) might consider this special
> case wrt SoftReferences as "more severe" given the stated guarantees
> around SoftReferences and OOME. (Side question: does the JVM's stated
> semantics guarantee that all unreachable objects will be cleared
> before OOME?)

After some internal discussion we will keep the priority as is.

The given symptoms were present before this particular reproducer (OOME 
without clearing soft references). The only difference is that this 
reproducer particularly emphasises it, and the workaround to increase 
the gc locker retry count (or move to JDK 22+ if G1 is your selected GC 
algorithm) seems very simple to implement, and persistent.

> I don't know if that warrants trying to solve this special case
> separately from the general case - I'm not a GC developer, but I could
> imagine a SoftReference-only clearing path that followed hard
> references through to SoftReferences and only cleared those (without
> going through a full GC cycle).

Marking through the object graph is a very large part (90%+) of full gc 
if you don't move objects. One needs to mark through all of it to 
correctly determine reachability. Just marking through does not 
guarantee that there is actually free space available too, so typically 
some compaction is necessary too, which basically requires an "almost" 
full gc anyway.

In this reproducer, all GCs do their equivalent of a full gc (either 
stw, or allocation stall).

> 
> I wonder if this might motivate JEP 423 backports?

The "Implement JEP 423" CR is already fairly large, in addition to that 
there were many changes not yet in JDK 23 that allow good performance, 
which makes backporting far from trivial.

Hth,
   Thomas