ghc releasing memory during compilation

[Simon Marlow]

Bulat Ziganshin wrote:

> 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.  The code is fairly readable, most of the auto-tuning of GC 
happens at the top level of GarbageCollect() in GC.c.  The main 
complexities are due to handling the difference between -H and no -H, 
and the fact that a 1-generation setup is quite different from a 
2-or-more-generation collector.

> 4. i still don't understand - wgen GHC performs copying GC, whether it
> copies data from old pages sequential or not? if it releases old pages
> sequentially, we can run copying GC using the same amount of physical ram
> as required for compaction gc

I think you're a bit confused about how copying GC works.  Only when the 
graph has been fully traversed can the old from-space area be discarded; 
until then, there might be live objects anywhere in it.  Furthermore, 
GHC's block allocation layer means that memory fragmentation can prevent 
freeing of unused memory: memory can only be freed in units of 
MegaBlocks (1Mb), but a megablock cannot be freed unless it has no 
active blocks in it.  (see my earlier reply to Duncan about this). 
Regardless of this, madvise()-style freeing can always be used.

Cheers,
	Simon