<div dir="ltr">Hey,<div><br></div><div>thanks, all! Measuring with `-A1M -F1` delivers much more reliable residency numbers.</div><div>`-F` doesn't seem to be documented. From reading `rts/RtsFlags.c` and `rts/sm/GC.c` I gather that it's the factor by which to multiply the number of live bytes by to get the new old gen size?</div><div>So effectively, the old gen will 'overflow' on every minor GC, neat!</div><div><br></div><div>Greetings<br>Sebastian</div></div><br><div class="gmail_quote"><div dir="ltr">Am Do., 6. Dez. 2018 um 12:52 Uhr schrieb Simon Peyton Jones via ghc-devs <<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">|  Right. A parameter for fixing the nursery size would be easy to implement,<br>
|  I think. Just a new flag, then in GC.c:resize_nursery() use the flag as the<br>
|  nursery size.<br>
<br>
Super!  That would be v useful.<br>
<br>
|  "Max. residency" is really hard to measure (need to do very frequent GCs),<br>
|  perhaps a better question to ask is "residency when the program is in state<br>
|  S".<br>
<br>
Actually, Sebastian simply wants to see an accurate, reproducible residency profile, and doing frequent GCs might well be an acceptable cost.  <br>
<br>
Simon<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>