ghc releasing memory during compilation

[Bulat Ziganshin]

Hello Ketil,

Wednesday, March 22, 2006, 11:02:49 AM, you wrote:

of course, any complicated algorithm can be a result of long
researches and so we are far from such algorithms. my words is more a
rhetorical point than concrete suggestion. that's real on this moment:

1) tune the ghc algorithm to kill "worst cases", especially disk
swapping

2) make the ghc's internal GC tuning features more accessible (it's
really more a question of documenting than adding/changing APIs) so
that anyone who need a specific GC tuning algorithm for his own
program can implement it himself

3) document the GC and GC tuning details

>>> and moreover, we should perform compaction immediately when swapping grows.
>>> imagine for example algorithm that had 80 mb residency and runs on a
>>> machine with 100 mb free. performing compacting GC each time when
>>> memory usage grows to 100 mb should be better strategy than waiting
>>> for 160 mb usage. of course, concrete calculation whether to start GC
>>> or not, is a delicate task, but at least it should be performed on
>>> each minor GC

>> I'd like to urge you to have a go at implementing some of these
>> strategies.

KM> I must admit that I am slightly skeptical to complicated heuristics
KM> here, since it seems actual performance would depend a lot on memory
KM> manangement policies of the underlying OS.

KM> However, I find that setting GHC to use the equivalent of +RTS -Mxxx
KM> where xxx is about 80% of physical RAM generally works well.
KM> Currently, I do this through a C file reading values from sysconf(),
KM> which is a bit cumbersome.  A way to set these defaults though the ghc
KM> command line would be welcome.

KM> -k



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