yishaigalatzer/ExtreMem-768MB-Shen-Param

## 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.
	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
	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.