[Haskell-cafe] GC

[John Lask]

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.


----- Original Message ----- 
From: "wren ng thornton" <wren at freegeek.org>
To: <haskell-cafe at haskell.org>
Sent: Friday, May 08, 2009 9:33 AM
Subject: Re: [Haskell-cafe] GC


> Daniel Fischer wrote:
>> Am Donnerstag 07 Mai 2009 22:01:11 schrieb Andrew Coppin:
>> > Simon Marlow wrote:
>> > > http://hackage.haskell.org/trac/ghc/ticket/698
>> > I presume that the reason for this is to avoid handing memory back only
>> > to immediately need it again? (I.e., we don't want to be constantly
>> > asking the OS to allocate and deallocate memory. Allocate it once and
>> > then let the RTS handle it.)
>> >
>> > How hard would it be to add a function to ask the RTS to shrink the
>> > allocated memory? E.g., you do something that you know consumes lots of
>> > RAM, you finish doing it, you know that your live set has probably gone
>> > way down now, so you ask the RTS to release some RAM if possible. Would
>> > that be difficult?
>>
>> Another idea, I have no idea how hard or sensible it is:
>> What if the GC detects how much memory is currently used (it does already 
>> do that, doesn't it?) and how much is allocated from the OS, and if less 
>> than a third or a quarter of the allocated memory is used, return the 
>> memory that exceeds twice the used memory to the OS?
>> Behaviour might be configurable by an RTS flag.
>
> +1 (assuming the GC does detect current usage).
>
> I think this behavior (with flags to tune the multiples, or to disable it) 
> is nicely high-level and easy for users to reason about.
>
> For users with intimate knowledge of the GC and their program's behavior 
> it could be helpful to have the alternative proposal of an impure function 
> to give hints to the RTS, but in general this seems like far too low-level 
> of an approach to solve the general problem.
>
> -- 
> Live well,
> ~wren
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>