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

Eliot Miranda notifications at github.com
Mon Dec 3 23:03:08 UTC 2018

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

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

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:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181203/fb996616/attachment.html>

More information about the Vm-dev mailing list