The observation is that often, the reason we experience bad progress following a degenerated cycle is because of an overabundance of floating garbage. Triggering a full GC for the sole purpose of reclaiming floating garbage is overkill in GenShen. A full GC may require over 2 second of pause time, whereas a degenerated young GC can achieve nearlythe same results in only a few hundred ms.

Instead of always triggering Full GC if degenerated GC has bad progress, only upgrade to full GC after two consecutive degenerated cycles with bad progress.

A workload that demonstrates the value of this alternative approach is the following:
```
 ~/github/jdk.defer-generational-full-gc/build/linux-x86_64-server-release/jdk/bin/java \
            -XX:+UnlockExperimentalVMOptions \
            -XX:-ShenandoahPacing \
            -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -Xms$s -Xmx$s \
            -XX:ShenandoahOldEvacRatioPercent=30 \
            -XX:ShenandoahMinimumOldTimeMs=25 \
            -XX:ShenandoahLearningSteps=8 \
            -XX:ShenandoahFullGCThreshold=1024 \
            -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational \
            -Xlog:"gc*=info,ergo" \
            -Xlog:safepoint=trace -Xlog:safepoint=debug -Xlog:safepoint=info \
            -XX:+UnlockDiagnosticVMOptions \
            -jar ~/github/heapothesys/Extremem/target/extremem-1.0-SNAPSHOT.jar \
            -dInitializationDelay=45s -dDictionarySize=16000000 -dNumCustomers=1400000 \
            -dNumProducts=320000 -dCustomerThreads=2000 -dCustomerPeriod=6s -dCustomerThinkTime=1s \
            -dKeywordSearchCount=4 -dServerThreads=5 -dServerPeriod=5s -dProductNameLength=10 \
            -dBrowsingHistoryQueueCount=5 \
            -dSalesTransactionQueueCount=5 \
            -dProductDescriptionLength=32 -dProductReplacementPeriod=25s -dProductReplacementCount=10 \
            -dCustomerReplacementPeriod=30s -dCustomerReplacementCount=1000 -dBrowsingExpiration=1m \
            -dPhasedUpdates=true \
            -dPhasedUpdateInterval=30s \
            -dSimulationDuration=20m -dResponseTimeMeasurements=100000
```
Five consecutive runs of this workload on tip reported an average of 15 full GCs per run, with a maximum number of Full GCs of 55.

With the proposed alternative approach, five consecutive runs have an average of 0.4 full GCs, maximum full GCs of 1. Each of the full GCs in this alternative configuration resulted from allocation failure during evacuation.