Preliminary patch for #814 - more flexible memory handling in
simonmarhaskell at gmail.com
Mon Aug 21 07:01:27 EDT 2006
Thanks very much for the patch. A couple of general comments:
- use stgMallocBytes/stgFree rather than malloc/free, since these include
- style: we normally use braces even when they aren't necessary (there's a
slightly-ancient style guide in docs/comm/rts-libs/coding-style.html).
Esa Ilari Vuokko wrote:
> Bulat, my apologies if you're not interested in details, but I recall
> you took part in the earlier discussion about this issue. Would you
> be interested at testing this or final patch?
> Well, I took a quick take on #814 , more flexible memory handling
> in Windows. Attached is the preliminary patch. I tested the patch
> by running fast testsuite with stage2 compiler using the patched rts.
> Apologies if someone else is working on this.
> * Naturally, only affects Windows.
> * keep two (singly) linked lists, one for VirtualAlloc MEM_RESERVEs
> and one for unused bits of memory that merges pieces near each
> * Memory is only committed when actually given to the rts/gc, so
> reserving big chunks is still a valid tactic - reserving memory only
> takes address space, it doesn't show in memory use or take space in
> * It certainly isn't blazingly fast, but I don't think it's that bad
I don't think speed is critical in this part of the system, so clarity is
more important than performance.
> * It uses malloc/free for allocating bookkeeping structures, but because
> that's low memory consumption, there shouldn't be problems with memory
> fragmentation. The other choice is to take something around 10-20k
> for static arrays (for 32bit Windows).
dynamic allocation is fine.
> * Support for freeing memory (atleast decommitting) is easy to add, in
> case gc supports that in future.
> * Currently, it reserves n+1 blocks when needed, but this obviously
> should be configurable. Is there a good name, or existing, option
> I should use for it? I'd say 32M/64M is a good default, that way we
> can keep even the worst case reservation crud in few percent.
On Unix we ask for n+1, then de-allocate the unused parts. Most OSs settle down
and provide aligned blocks from then on. I don't mind what you do on Windows,
allocating in 32 or 64M chunks sounds reasonable.
More information about the Cvs-ghc