<div class="gmail_quote">On Mon, Feb 7, 2011 at 3:59 AM, John B Thiel <span dir="ltr"><<a href="mailto:jbthiel@gmail.com">jbthiel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
on a 1.66GHz/1GB ram/mswin7 notebook (well
loaded, 12+ apps open)</blockquote><div><br>This sounds like the root of the problem. With 1GB of physical RAM, MLton decides to use up to 512MB of it. Given you have 12+ apps open, it seems quite likely that the other apps have a combined working set + pinned pages exceeding the 512MB. Hence the thrashing.<br>
<br>The policy of "half of physical RAM" is just a rule of thumb. The more heavily loaded your machine (as a percentage of physical RAM) the less appropriate it becomes.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It seems there is some runaway allocation with the default options on<br>
Windows, that unnecessarily overdrives into swap/thrashing.<br></blockquote><div><br>I don't think it's runaway allocation. <br></div></div><br>If I recall correctly, MLton will use copying collection with a heap size of twice the live set up until this would exceed the 50% mark. Since we've established that your hello-world program needs ~100MB, MLton will allocate 400MB. That leaves 600MB for everything else during a garbage collection. I believe Windows 7 takes somewhere in the ballpark of 200-300MB on its own, so that leaves just 300MB for your 12+ applications.<br>
<br>So, my suggestions: <br>1. buy another 1GB of memory which should solve your problem outright (MLton will leave 1GB to the other 12+ apps, which must be enough since you have that much memory at the moment)<br>2. close all the applications you can while working on your MLton-compiled projects<br>
<br>Keep in mind that for larger projects 100MB will not be enough to compile them.<br><br>