[MLton] cygwin and mmap
Matthew Fluet
fluet at tti-c.org
Fri Jun 19 18:41:06 PDT 2009
On Fri, 19 Jun 2009, Matthew Fluet wrote:
> One caveat is that, thus far, the virtual machine has been configured with 4G
> memory (although Windows only reports seeing 3G), so the garbage-collector
> and virtual-memory systems are not being stressed terribly. I'll try
> configuring down to 2G (and maybe down to 1G) and see if things remain
> stable.
I was able to self-compile with both 'use-mmap true' and 'use-mmap false'
with 1G memory. Here are the GC summaries:
[fluet at winxp-cygwin mlton]$ cat use-mmap-true.1g.log
GC type time ms number bytes bytes/sec
------------- ------- ------- --------------- ---------------
copying 7,079 13 591,616,636 83,573,476
mark-compact 82,454 13 3,080,548,832 37,360,817
minor 116,210 673 5,799,126,212 49,902,125
total time: 612,953 ms
total GC time: 212,214 ms (34.6%)
max pause time: 14,500 ms
total bytes allocated: 66,623,505,512 bytes
max bytes live: 656,260,600 bytes
max heap size: 745,406,464 bytes
max stack size: 14,499,840 bytes
num cards marked: 22,228,445
bytes scanned: 7,418,450,504 bytes
bytes hash consed: 0 bytes
[fluet at winxp-cygwin mlton]$ cat use-mmap-false.1g.log
GC type time ms number bytes bytes/sec
------------- ------- ------- --------------- ---------------
copying 7,110 13 590,547,480 83,058,713
mark-compact 78,845 13 2,834,232,564 35,946,890
minor 108,872 596 5,517,453,328 50,678,349
total time: 523,937 ms
total GC time: 201,145 ms (38.4%)
max pause time: 14,657 ms
total bytes allocated: 66,624,783,712 bytes
max bytes live: 656,260,600 bytes
max heap size: 745,406,464 bytes
max stack size: 14,090,240 bytes
num cards marked: 19,761,168
bytes scanned: 6,590,745,560 bytes
bytes hash consed: 0 bytes
Both memory managers were able to achieve the same maximum heap size.
Somewhere along the way, the garbage collections got out of sync, probably
due to some heap allocation or resizing request failing and requiring a
backoff. Although the 'use-mmap true' run is a little slower (that might
simply be due to the fact that I ran it immediately before the 'use-mmap
false' run, so it incured the cost of paging everybody else out), since it
provides more functionality, I will make it the new default.
For the record, here are the corresponding runs with 4G:
[fluet at winxp-cygwin mlton]$ cat use-mmap-true.4g.log
GC type time ms number bytes bytes/sec
------------- ------- ------- --------------- ---------------
copying 3,981 10 284,825,700 71,546,268
mark-compact 48,126 9 1,312,785,960 27,278,101
minor 99,795 300 5,320,801,552 53,317,318
total time: 508,968 ms
total GC time: 165,061 ms (32.4%)
max pause time: 8,891 ms
total bytes allocated: 66,610,123,092 bytes
max bytes live: 271,678,984 bytes
max heap size: 1,172,111,360 bytes
max stack size: 10,960,896 bytes
num cards marked: 16,782,779
bytes scanned: 5,121,248,816 bytes
bytes hash consed: 0 bytes
[fluet at winxp-cygwin mlton]$ cat use-mmap-false.4g.log
MLton finished in 371.52 + 174.24 (32% GC)
GC type time ms number bytes bytes/sec
------------- ------- ------- --------------- ---------------
copying 2,813 9 208,347,896 74,066,087
mark-compact 52,954 10 1,502,771,236 28,378,804
minor 108,915 325 5,805,274,292 53,300,960
total time: 506,203 ms
total GC time: 174,272 ms (34.4%)
max pause time: 8,719 ms
total bytes allocated: 66,619,945,340 bytes
max bytes live: 269,871,128 bytes
max heap size: 1,172,111,360 bytes
max stack size: 10,960,896 bytes
num cards marked: 17,969,572
bytes scanned: 5,412,110,084 bytes
bytes hash consed: 0 bytes
Again, same maximum heap size (and negligible difference in running time).
Also, the run with fewer minor gcs is fipped, so I don't think there is
a significant difference between the two.
More information about the MLton
mailing list