[MLton-user] Memory management C/SML

[Matthew Fluet]

On Thu, Apr 28, 2011 at 6:00 AM, Wesley W. Terpstra <wesley at terpstra.ca> wrote:
> On Thu, Apr 28, 2011 at 11:40 AM, Alexandre Hamez
> <alexandre.hamez at gmail.com> wrote:
>>
>> I've got the following use case: I'm generating a C library, for
>> efficiency and space reasons, which is dynamically open by the SML part.
>> This library can easily produce several GB of memory.
>
> 32 or 64 bit machine? If 64-bit, I wouldn't worry too much.
>

Agreed; fragmentation and contiguous memory is with respect to the
virtual address space.  With 64-bit addresses (and, even with the
40-bit or 48-bit addresses that are really used by the memory system)
there is almost never a problem finding sufficient contiguous virtual
addresses.

>> I'm trying to allocate blocks in a contiguous way to avoid fragmentation.
>> In this context, are there good practices to manage memory on the C side?
>
> Keeping your C memory use in a big contiguous chunk is about the best you
> can do. You might also consider telling MLton to limit it's assessment of
> the available physical memory via '@MLton ram-slop x --' to reduce paging
> out your C memory during a garbage collection.

The "@MLton fixed-heap x --" is also a possibility.  If you can
(over-)estimate the memory requirements of the SML portion of the
program, then a fixed-heap will allocate a heap of that size at the
beginning of execution.