[Haskell-cafe] GC

[Jason Dagit]

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.


Definitely.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090509/a2aa7884/attachment.htm