It looks like some platforms have problems with memory mangement. I observed
a similar problem with the Win32 binary, too. On Windows NT everything is
OK. Using Windows 95/98 (on my home machine) I have got the message:
getMBlocks: MapViewOfFileEx failed with: 487
TEST.EXE: fatal error: GetMBlock: mmap failed
I looked into the source of GHC's runtime system (Ver 4.00) and found a call
of MapViewOfFileEx with the base address 0x50000000. This may work on
Windows NT, but there is a small risk, that this address may be used by some
other memory manager (malloc, etc.).
The comments in this suggest that the GHC developers are interested in
information about how to allocate memory for the different platforms.
Here is some information for Win32:
On Window 95/98 mapped files work significantly different (KB Article
Q125713: Common File Mapping Problems and Platform Differences). First at
all mapped files must be inside the region from 2GB to 3GB (NT: 0GB to 2GB).
An (incomplete) fix would be to let MapViewOfFileEx select the memory
address with the first call. Simly call it with a base address of 0. But
it's not sure that you can extend the memory at the end, because other
memory managers. Further, the region from 2GB to 3GB is shared between all
applications. So you will get security problems.
For me it looks like it is better to use the VirtualAlloc-Function to
reserve memory. It allows to reserve a huge address region (1GB for
example), without commiting virtual memory inside of this region. This
region will not be used by other memory mangers. The virtual memory can be
commited incrementally, when it is really needed.
Further, you can mark pages at the end of a stack with PAGE_NOACCESS
(PAGE_GUARD work only with NT!) and get exceptions, that resize the stack,
without having stack checks in your program.
I hope this hints help, to make GHC memory managment better on Win32
platforms. If not, discard it.
Cheers,
Herbert
