Updates to FFI spec: performGC
Manuel M T Chakravarty
chak at cse.unsw.edu.au
Tue Sep 10 04:38:43 EDT 2002
Alastair Reid <alastair at reid-consulting-uk.ltd.uk> wrote,
> > Hmmm, the garbage collector is a black box and has its own
> > complicated heuristics for managing memory usage, but you are
> > describing a mechanism that depends rather heavily on certain
> > assumed behaviours. At the least, that gives the garbage collector
> > less flexibility to change its own behaviour, lest it invalidate the
> > assumptions made by the external allocator.
> This is a situation where something is better than nothing. The
> heuristics we used with Hugs were pretty lame -I don't think they even
> worked as I'd intended- but they were good enough to get the job done.
> In fact, the application ran brilliantly: small GC pauses, little
> wasted memory.
I am not sure what to do with this one. SimonM, did
Alastair convince you by now that what he proposes is
useful? I understand the problem, but I am also not really
sure whether the proposed solution would work portably.
If performGC gets a kind of "forcefulness" level in the form
of natural number (0 ~ GC if you like to, ..., 9 ~ do a
major GC and get rid of everything you can), implementations
would be free to more or less ignore the parameter (might
have a simple two-space collector) or try to provide several
levels of GC (in whatever way fits into the GC policies of
the implementation). Nevertheless, it should still help
Alastair when using a system that honours use of the
More information about the FFI