Preliminary patch for #814 - more flexible memory handling in Windows

[Simon Marlow]

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