On Sat, Dec 12, 2009 at 8:48 AM, 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;">
It isn't quite sequential access.</blockquote><div><br>Sorry. You're both wrong. ;) The mremap code does a memcpy, which is 100% sequential. That's the only transition between the two heaps on Windows -> inside mremap. It allocates the new heap, memcopies them, then frees the old heap. The only time the GC touches it is when it fixes up the addresses.<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;"><div class="im">> I have a higher-level solution proposal: MLton.GC already has hooks that are<br>
> executed after a GC to implement finalizers. Expose these to the user. If a<br>
> user knows his application only consumes X memory on an error condition, he<br>
> can test for this after a GC and terminate with an "Out of Memory" error as<br>
> desired.<br>
<br>
</div>You still need to get out of the GC before the GC signal handler runs.<br></blockquote><div><br>Of course, but we are talking about early detection. Under normal operation his program probably uses >much< less than the total RAM. Stopping at 1GB with an error would certainly be earlier than thrashing set in. <br>
<br>Right now we are focusing in on a micro-program which just consumes memory and we're talking about how to optimize it. It's a pathological program! We should instead be supporting David's underlying goal: detecting when his program enters run-away RAM consumption. This happens much much sooner than thrashing.<br>
</div><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">
>> the mremap function is described as using the Linux page table scheme to<br>
>> efficiently change the mapping between virtual addresses and (physical)<br>
>> memory pages. It's purpose is to be more efficient than allocating a new<br>
>> map and copying.<br>
><br>
> If I could ...<br>
<br>
</div>I guess my point is that the way that you indicate that you aren't<br>
more efficient than alloc/copy is by not providing mremap. Everything<br>
else in the generic implementation with attempting the in place expand<br>
is more efficient; it is just the starting off with the alloc/copy<br>
that doesn't seem to make sense.<br></blockquote><div><br>As already mentioned, the design goal for windows mremap was not efficiency, but to use more virtual address space. I think both agree that alloc/copy as the last step makes more sense for 64-bit systems to reduce the likelihood of thrashing.<br>
<br></div></div>