If a request to interrupt an old cycle is accepted, but there is an allocation failure before the requested cycle begins, then the control thread may become stuck in a state where it believes it should ignore further concurrent cycle requests.

I was able to reproduce this problem using this script:
```
ITERATIONS=$1

for i in $(seq 1 $ITERATIONS)
do
  $HOME/Development/genshen/build/linux-x86_64-server-release/jdk/bin/java \
   -XX:+UnlockExperimentalVMOptions \
   -XX:-ShenandoahPacing \
   -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -Xms32g -Xmx32g \
   -XX:+UseShenandoahGC \
   -XX:ShenandoahGCMode=generational \
   -Xlog:"gc*=info,ergo,gc+thread=debug:file=/tmp/extremem.${i}.log::filecount=0,filesize=0" \
   -XX:+UnlockDiagnosticVMOptions \
   -jar /tmp/extremem-1.0-SNAPSHOT.jar \
   -dInitializationDelay=45s -dDictionarySize=16000000 -dNumCustomers=28000000 \
   -dNumProducts=64000 -dCustomerThreads=2000 -dCustomerPeriod=6s -dCustomerThinkTime=1s \
   -dKeywordSearchCount=4 -dServerThreads=5 -dServerPeriod=5s -dProductNameLength=10 \
   -dBrowsingHistoryQueueCount=5 \
   -dSalesTransactionQueueCount=5 \
   -dProductDescriptionLength=64 -dProductReplacementPeriod=25s -dProductReplacementCount=5 \
   -dCustomerReplacementPeriod=30s -dCustomerReplacementCount=1000 -dBrowsingExpiration=1m \
   -dPhasedUpdates=true \
   -dPhasedUpdateInterval=60s \
   -dSimulationDuration=20m -dResponseTimeMeasurements=100000
 done
```