ghc releasing memory during compilation

Bulat Ziganshin bulat.ziganshin at gmail.com
Thu Mar 16 03:07:35 EST 2006


Hello John,

Thursday, March 16, 2006, 4:00:34 AM, you wrote:

>> i suggest checking of AVAILABLE physical ram, that is perfectly
>> possible in windows

JM> the problem is that available physical ram is wasted ram. any good os
JM> will never let there be any available ram because it will fill it up
JM> with disk buffers if nothing else.

yes, but nevertheless really good operating systems report the avail
ram what includes cache buffers. for not-so-good OSes disk cache can
be a good measure ;)

JM> the only time actual available ram
JM> appears is when a big application quits, but then it quicky fills up due
JM> to normal disk activity. determining how much of those buffers/cached
JM> info you can push out without adversly affecting system performance or
JM> thrashing is not very easy so at best we get a sort of approximation.

John, not all algorithms are well determined. what we need is just to
get "better behavior" in the most of cases

JM> the best solution would be for ghc's garbage collector to periodically
JM> call getrusage(2) and look at the number of page faults and swaps it is
JM> causing and switch to compaction when it sees a jump in that. I don't
JM> know what the equivalent routine on windows would be. not all operating
JM> systems fill in all the values of getrusage, BSD is the best, linux is
JM> the worst at this. but on linux you can get similar info from
JM> /proc/self. (i think it does fill in the values we need in getrusage
JM> though, I forget which ones it doesn't have)

i agree tha this should be even better. windows have such mechanism.
but it will be interesting if all our optimization tricks will work
only with superuser privileges :)



-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com



More information about the Glasgow-haskell-users mailing list