<div class="gmail_quote">On Thu, Apr 28, 2011 at 11:40 AM, Alexandre Hamez <span dir="ltr"><<a href="mailto:alexandre.hamez@gmail.com">alexandre.hamez@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br></blockquote><div>
<br>32 or 64 bit machine? If 64-bit, I wouldn't worry too much.<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;">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.</blockquote>
<div><br>Yep. (I take your 'a process memory' to mean 'the memory MLton uses for the SML heap in that process')<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;">
I'm trying to allocate blocks in a contiguous way to avoid fragmentation.<br>In this context, are there good practices to manage memory on the C side?<br></blockquote><br></div>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.<br>
<br>