[Haskell-cafe] GC

Jason Dagit 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...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090509/a2aa7884/attachment.htm

More information about the Haskell-Cafe mailing list