SoftReferences not cleared before OOME

[Devin Smith]

I very much appreciate the follow-up. This all seems sensible to me.
The other option I have is to reduce / remove the usage of libraries
which rely on Get*Critical JNI, which is easier said than done...

Thanks again,
-Devin


On Mon, Jun 17, 2024 at 12:34 AM Thomas Schatzl
<thomas.schatzl at oracle.com> wrote:
>
> 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