[MLton] cygwin and mmap

[Matthew Fluet]

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.