[MLton] Extra GC pressure

[Wesley W. Terpstra]

On Feb 22, 2007, at 4:11 PM, Matthew Fluet wrote:
> The real point being that MLton uses a contiguous heap, so we want  
> to allocate that heap early and keep reusing it; it is best to grab  
> the heap before a lot of C code gets a chance to fragment the  
> virtual memory space with individual mallocs.

This also means that the C and SML memory are disjoint, so coupling  
them is a bad abstraction.

> While it wouldn't be hard to add MLton.GC.{add,sub}Memory, I'm not  
> sure how we could best act on that.  We could artificially  
> manipulate the limit pointer, thereby triggering a GC earlier.   
> But, you'd need to be careful about rolling the limit pointer  
> beyond the frontier or beyond the true limit.

That shouldn't be too hard..?

>> The idea being that if you have an SML object that is backed by a  
>> C object (for example SQLite, GTK, etc), you can indicate to the  
>> GC how much memory (approximately) the C-side is consuming. When  
>> you free that memory, you tell the GC that the memory pressure has  
>> been reduced. The goal of this is to help trigger a GC earlier to  
>> clean up SML objects (and thus their attached C state).
>
> I can imagine the situation you describe, but have you encountered  
> it in practice?

Not yet.

However, I've also not written a program in SML that uses this many C  
structures. Actually, this can be done without any changes to MLton,  
so that's probably the best route. I am imagining that I keep a  
global 'cUsage' counter that is incremented/decremented on allocation/ 
free. When an increment makes it too large, trigger a GC, look at the  
value after GC and set the limit (for another GC) to twice that.