Updates to FFI spec: performGC

[Manuel M T Chakravarty]

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
forcefulness level.

Manuel