Alastair Reid <alastair@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