ExtreMem-768MB-Shen-Param

Running Shenandoah GC with 768M heap size
JVM configuration:
-Xlog:gc:batch.shenandoah-gc.768M.log -XX:+AlwaysPreTouch -XX:+UseLargePages
-XX:-UseBiasedLocking -XX:+DisableExplicitGC -Xms768M -Xmx768M
-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:+ShenandoahPacing
-XX:ShenandoahPacingMaxDelay=1

Extremem configuration
RandomSeed,42
InitializationDelay,50000
SimulationDuration,600000000
DictionarySize,50000
DictionaryFile,/usr/share/dict/words
BrowsingHistoryQueueCount,10
SalesTransactionQueueCount,10Server thread configuration
ServerThreads,10
ServerPeriod,500000
Customer maintenance
CustomerReplacementPeriod,60000000
CustomerReplacementCount,0
Product maintenance
ProductReplacementPeriod,90000000
ProductReplacementCount,64Customer thread configuration
CustomerThreads,20000
CustomerPeriod,240000000
CustomerThinkTime,200000000
BrowsingExpiration,600000000Customer configuration
NumCustomers,10000
KeywordSearchCount,5
SelectionCriteriaCount,8
BuyThreshold,0.4
SaveForLaterThreshold,0.4Product configuration
NumProducts,20000
ProductNameLength,5
ProductDescriptionLength, 24
ProductReviewLength,32

MemoryAndPatterns.txt

The 768 MB execution was 72% utilized, meaning 28% of 768 MB = 215 MB was head room.
The allocation rate was ~126 MB/s.  
The 544 MB (768 - 215 = roughly 544) of live memory consists of roughly 
     79 MB that is very long lived memory 
     465 MB that is transient memory (allocated and discarded regularly). 75% of that memory lived for 200 seconds
     
In more details: 
A "large" percentage (probably more than 75%) of the transient memory lived 200 seconds plus small delta because there are 20,000 customer threads, each of which is repeatedly carrying out "transactions" which include 200 seconds of "think time".  During each think time, the customer thread sits on a bunch of private data that was allocated specifically for the intent of supporting their transaction.

Thanks @kdnilsen, fixed and added a description of the situation based on our discussion