Shenandoah is designed to be "pause-less", and GC is supposed to run concurrently with mutator threads. If properly configured for a particular workload, Shenandoah will not experience OOM. When it does experience OOM, that suggests that the JVM has not been properly configured for this workload and concurrent operation of GC is not feasible.

As currently implemented, Shenandoah sometimes takes much too long retrying failed allocation requests, during which mutator threads are blocked waiting for multiple urgent stop-the-world (degenerated or full) GC cycles to complete. In these situations, fast failure would probably be a preferred behavior so that workload can be redistributed to other services and this particular JVM can be restarted in a better state.

Another problem that has been observed is that Shenandoah, as currently implemented, sometimes throws OOM when it would not be appropriate. The following failure has been observed with the gc/shenandoah/oom/TestThreadFailure.java jtreg test:

1. For NastyThread-0 through NastyThread-11, we perform a FullGC (which has good progress) but the good progress is not enough to satisfy the failed allocation request so we throw OOM.

2. With NastyThread-12, we do not fail fast. GC(127) is concurrent young. GC(128) through GC(132) are Full GCs, each with Bad Progress, but each yielding enough free memory to satisfy at least one additional allocation by NastyThread-12.

3. GC(133) is a full GC also with bad progress. This time, the bad progress is not enough to satisfy the pending alloc request (for 4112 bytes), so we throw OOM.

4. At this point, we have experienced 5 (Default value of ShenandoaohNoProgressThreshold) consecutive full GCs with no progress, so when the main thread attempts to allocate NastyThread-13 after joining with NastyThread-12, it does not even bother to attempt a Full GC. It just immediately throws OOM.

5. This causes the test to fail, because main is not "supposed" to experience OOM.





Exception in thread thread_name: java.lang.OutOfMemoryError: GC Overhead limit exceeded
    Cause: The detail message "GC overhead limit exceeded" indicates that the garbage collector is running all the time and Java program is making very slow progress. After a garbage collection, if the Java process is spending more than approximately 98% of its time doing garbage collection and if it is recovering less than 2% of the heap and has been doing so far the last 5 (compile time constant) consecutive garbage collections, then a java.lang.OutOfMemoryError is thrown. This exception is typically thrown because the amount of live data barely fits into the Java heap having little free space for new allocations.