[MLton] Extra GC pressure
Wesley W. Terpstra
wesley at terpstra.ca
Thu Feb 22 07:53:21 PST 2007
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.
More information about the MLton
mailing list