dagit at codersbase.com
Sat May 9 03:06:46 EDT 2009
On Fri, May 8, 2009 at 2:37 PM, Andrew Coppin
<andrewcoppin at btinternet.com>wrote:
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe