[MLton] Fwd: tuning up mlton gc

---------- Forwarded message ----------
From: Bernard Berthomieu <[email protected]>
Date: Mon, Jul 21, 2014 at 10:44 AM
Subject: tuning up mlton gc
To: Matthew Fluet <[email protected]>, Stephen Weeks <[email protected]>


Dear Matthew and Stephen,

Sorry to mail this to you personnally. If you think this message
is likely of interest to mlton users, please feel free to forward it to
the list.

We are using mlton at our place to implement model-checking tools.
We are quite happy with it, but the cost of garbage collection in our
applications always bothered me. Our applications typically generate
a lot of data, a large percentage of which is persistent (state spaces).
I guess this is the kind of applications that would most benefit from
generational garbage collection.

I observed that mlton does not start with generational gc, but rather
with a simple two-space copying, possibly switching later to generational,
upon some conditions. I could not find in the mlton sources a simple
way to force generational garbage collection from the start, but I've
found that some gc constants could be tuned by the user (though these
options are not documented).
After some experiments, I found that setting live-ratio to 4.0,
rather than the default 8.0, consistently resulted in a significant
speedup of my applications.

My understanding is that decreasing live-ratio prompts generational
garbage collection to occur earlier, which greatly cuts gc cost here.
The attached files show gc-summary for the two values of this option
on a typical run (in 32 bit).

My questions are:

1. Do you agree with this analysis of the improvement ?

2. Are there some way other than playing with ratios (which could
have some undesired effects as well) to have mlton always use
generational gc ? I don't mind having to recompile mlton or the runtime.

3. Would there be any drawbacks to do so ?


Thanks for any hints, and for maintaining mlton alive !
   Bernard Berthomieu.

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds

_______________________________________________
MLton-devel mailing list
[email protected]; [email protected]
https://lists.sourceforge.net/lists/listinfo/mlton-devel

GC type		time ms	 number		  bytes	      bytes/sec
-------------	-------	-------	---------------	---------------
copying		 10,756	     41	  1,297,981,800	    120,675,141	
mark-compact	      0	      0	              0	              -	
minor		 19,618	  2,385	  1,533,602,796	     78,173,249	
total time: 298,893 ms
total GC time: 34,290 ms (11.5%)
max pause time: 1,864 ms
total bytes allocated: 74,769,391,396 bytes
max bytes live: 113,256,392 bytes
max heap size: 452,575,232 bytes
max stack size: 11,680 bytes
num cards marked: 9,575
bytes scanned: 33,235,836 bytes
bytes hash consed: 0 bytes
[GC: Releasing heap at 0xcae00000 of size 452,575,232 bytes (+ 3,538,944 bytes card/cross map).]
[GC: Releasing heap at 0xafa00000 of size 452,575,232 bytes (+ 3,538,944 bytes card/cross map).]

GC type		time ms	 number		  bytes	      bytes/sec
-------------	-------	-------	---------------	---------------
copying		 89,939	    198	 11,324,133,444	    125,909,042	
mark-compact	      0	      0	              0	              -	
minor		      0	      0	              0	              -	
total time: 375,801 ms
total GC time: 100,724 ms (26.8%)
max pause time: 2,124 ms
total bytes allocated: 74,771,306,832 bytes
max bytes live: 115,179,268 bytes
max heap size: 882,425,856 bytes
max stack size: 12,480 bytes
num cards marked: 0
bytes scanned: 0 bytes
bytes hash consed: 0 bytes
[GC: Releasing heap at 0xc9600000 of size 882,425,856 bytes (+ 6,897,664 bytes card/cross map).]
[GC: Releasing heap at 0x94400000 of size 882,425,856 bytes (+ 6,897,664 bytes card/cross map).]