[MLton-user] Memory management C/SML

[Wesley W. Terpstra]

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.


> My understanding of the MLton memory management is that a process memory is
> handled in a single contiguous block, and that when more memory is needed,
> the GC might copy the whole block, thus needing a bigger block of free
> memory.


Yep. (I take your 'a process memory' to mean 'the memory MLton uses for the
SML heap in that process')


> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton-user/attachments/20110428/fc538857/attachment.html