Hi Esa,
Thanks very much for the patch. A couple of general comments:
- use stgMallocBytes/stgFree rather than malloc/free, since these include
error checking.
- 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 [1], 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.
Notes:
* 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
other.
* 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
pagefile.
* It certainly isn't blazingly fast, but I don't think it's that bad
either.
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.
Questions:
* 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.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
