TestGCLocker seems to be made with the assumption that GCs are triggered on allocation failure. It has a somewhat complicated machinery to generate some GC pressure and especially to free up some memory in its artificial MemoryUser. This leads to some weird interactions with Shenandoah control machinery.

For example, it frees memory when heap usage is >75% AND a certain time has passed since it last freed memory (500ms). In those 500ms, it will keep on allocating chunks of memory, eventually running OOM because it keeps holding on to those chunks, while the GC is running like mad trying to free up memory, but can't because the stupid up doesn't let go. However, it will still keep resetting timeSinceLastGC because of some tiny objects getting freed-up since last time (not enough to prevent OOM though).