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