On Fri, May 8, 2009 at 2:37 PM, Andrew Coppin
John Lask wrote:
on the other hand a function to release pool memory to the OS down to the current active level should (I hope) be easily implementable, and quickly incorporated into application where required, whereas arriving at one or more automatic deallocation policies would most likely require some analysis/trial and error.
I would suggest that trying to do this "automatically" in a way that is optimal for all applications requires some fairly serious heuristics.
OTOH, for many Haskell programs it isn't a problem in the first place. (E.g., if you write something like Darcs which only ever runs for a few seconds, you barely need GC in the first place.)
That's not entirely true. Darcs has a fair number of operations that stream data and hence work well because the RTS can recycle the memory and keep the usage at a constant. I think I see your point and agree in principle though. A similar argument can be applied to laziness. Often times you end up evaluating most or all of the thunks, so what difference did it make? But, I guess it's a bit of an oversimplification in both cases.
I'm just thinking, the application writer probably knows more about their specific program than the compiler designers do, so it would be nice to be able to provide hints to the RTS.
Definitely. Jason