On Mon, May 3, 2010 at 7:20 PM, Matthew Fluet <span dir="ltr"><<a href="mailto:matthew.fluet@gmail.com">matthew.fluet@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">> I noticed that the no-paging varient took more than 3.6GB of physical memory<br>
> in windows task manager (enough that my system thrashed). I didn't have task<br>
> manager open for the yes-paging test. Perhaps it is overestimating the<br>
> amount of physical memory and thus not stopping at 50% as it should? Or is<br>
> it the usual last-step resize = up to 2* maximum memory? Whatever is<br>
> happening, it's not ok to push a system to thrashing with default<br>
> parameters.<br>
<br>
</div>If you really don't want thrashing, then you need to set a "@MLton<br>
max-heap ??" to your physical memory. MLton's policy has always been<br>
to use as much memory as the application requires, subject only to the<br>
amount of memory obtainable from the operating system (unless max-heap<br>
sets a lower limit). MLton will try to size a heap to stay within<br>
physical memory (really, 50% physical memory with the default<br>
ram-slop), but if the live size of the application exceeds that and<br>
the operating system is willing to give over the memory, then MLton<br></blockquote><div><br>I wasn't thinking. You're right, of course. <br></div></div>