[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] A better default eden size for 64-bits (#316)

[Eliot Miranda]

The current default eden size for 64-bits is 8 Mb which is too small.  The performance cost of generation scavenging on 64-bits is radically different at 8Mb vs e.g. 64Mb.  For example, here are the GC stats and the time to run for recompiling the Morphic package in a trunk Squeak 640-bit image, collected by running

FileStream stdout print: [(PackageInfo named: 'Morphic') methods do:
	[:mr| mr actualClass recompile: mr selector]] timeToRun; cr.
FileStream stdout nextPutAll:
	(Smalltalk vm vmStatisticsReportString
		replaceAll: Character cr with: Character linefeed) 

squeak> 7061
uptime		0m 7s
memory		85,073,920 bytes
	old			76,121,888 bytes (89.5%)
	young		7,190,528 bytes (8.5%)
	used		54,408,216 bytes (64%)
	free		26,774,568 bytes (31.5%)
GCs			195 (38.2 ms between GCs)
	full		0 totalling 0 ms (0% runtime), avg 0 ms
	scavenges	195 totalling 82 ms (1.1% runtime), avg 0.4 ms
	tenures		21,139 (avg 108 tenures per scavenge)
Code compactions
	0

Aeolus.image$ spur64cfvm -eden 60m spurreader-64. <RecompileMorphicAndReport.st
squeak> 6968
uptime		0m 7s
memory		140,648,448 bytes
	old			76,121,888 bytes (54.1%)
	young		61,896,704 bytes (44%)
	used		62,854,824 bytes (44.7%)
	free		43,764,376 bytes (31.1%)
GCs			23 (318.5 ms between GCs)
	full		0 totalling 0 ms (0% runtime), avg 0 ms
	scavenges	23 totalling 30 ms (0.41% runtime), avg 1.3 ms
	tenures		0
Code compactions
	0

While the run-time varies very little (7 seconds to 6.97 seconds), the number of scavenges goes down enormously.  The reason the run-time is relatively unaffected is because the generation scavenger is quite efficient.  At an 8mb young space we see 195 scavenges with about a 1.1% runtime overhead.  But at a 64mb young space we see 23 scavenges (a ratio of about 8, which mirrors the ratio of the sizes), but the run-time overhead is now only 0.41%; 82ms overhead vs 30ms overhead.  So a larger young space is a good idea.

The suggestion here is that on 64-bit platforms we tailor the default young space size to the available memory.  See e.g. https://stackoverflow.com/questions/2513505/how-to-get-available-memory-c-g which provides code above sysconf on Unix and GlobalMemoryStatusEx on WIN32 for obtaining the total amount of physical memory available.  Therefore we could use a larger young space on systems with a lot more memory; for example 2Mb of young space per Gb of physical memory would give a 64-mb young space on 32Gb machines such as my fully loaded 2018 MacBook Pro Core i9.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/316
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181203/fb996616/attachment.html>