On Thu, Dec 10, 2009 at 7:08 PM, Wesley W. Terpstra <span dir="ltr"><<a href="mailto:wesley@terpstra.ca">wesley@terpstra.ca</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">On Thu, Dec 10, 2009 at 9:37 PM, Matthew Fluet <span dir="ltr"><<a href="mailto:matthew.fluet@gmail.com" target="_blank">matthew.fluet@gmail.com</a>></span> wrote:<br></div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Note, that while Windows doesn't natively support mremap, Wesley implemented a few things that try to mimic mmap/mremap/munamp functionality under Windows. There seems to be some complication with the Windows memory system that requires committing in addition to reserving memory, and some manner of being able to extend an existing map with space before it and after it. I don't understand it.</blockquote>
</div><div><br>When you reserve memory, you get virtual address space that does not overlap any previous reservations. When you commit (part of) that reservation, you get memory that can actually be used without segfaulting. <br>
</div></div></blockquote><div><br>That part makes sense; I was simply noting that you go to some lengths to use this facility in an efficient manner and I wasn't familiar enough with that code to change its behavior. <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="gmail_quote">Of course, even if mremap tries in-place heap growth first, this might not be possible, and a copy to a new memory location will still thrash.<br>
</div></blockquote><div><br>Absolutely.<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="gmail_quote"><div><div class="im">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
(This actually seems to be redundant with the behavior of the garbage collector proper.)</blockquote><br></div>Perhaps, but I was trying to implement an mremap compatible to the specification of mremap, not how MLton uses mremap. If mremap fails to aquire the desired space, mmap will certainly also fail.<br>
</div></div></blockquote><div><br>Fair enough. Although, and I freely admit that this is not necessarily part of the mremap specification, on Linux, the mremap function is described as using the Linux page table scheme to efficiently change the mapping between virtual addresses and (physical) memory pages. It's purpose is to be more efficient than allocating a new map and copying.<br>
<br></div></div>