[MLton] max-heap setting for 64-bit applications

[Matthew Fluet]

On Thu, Dec 10, 2009 at 7:08 PM, Wesley W. Terpstra <wesley at terpstra.ca>wrote:

> On Thu, Dec 10, 2009 at 9:37 PM, Matthew Fluet <matthew.fluet at gmail.com>wrote:
>
>> 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.
>
>
> 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.
>

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.

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.
>

Absolutely.

  (This actually seems to be redundant with the behavior of the garbage
>> collector proper.)
>
>
> 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.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20091211/b4e7695a/attachment.htm