Alastair Reid <[EMAIL PROTECTED]> 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 _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi