Another reason 64 bit is shit

A bit of background is in order. GHC allocates memory from the operating system in units of aligned megabytes. So it owns a collection of megabytes that might be anywhere in the address space. For every pointer it sees, the GC asks the question “is this a pointer into the heap?”, and the memory manager should return true for any of the memory that GHC has allocated, and false otherwise. This is the job of the HEAP_ALLOCED() macro.

On a 32-bit machine, answering the question is easy: a megabyte is 20 bits, so we only need a 12-bit lookup table, and even using a full byte for each entry, that’s just 4KB.

On a 64-bit machine, it’s much harder. Even taking advantage of the fact that only 48 bits are available address space on x86_64 architecture machines, that still leaves 28 bits, which is a 256MB table (32MB using bits instead of bytes). This is not likely to be an acceptable memory overhead.

https://simonmar.github.io/posts/2015-07-28-optimising-garbage-collection-overhead-in-sigma.html

>>12
No, the problem is with all the other platforms that let you overallocate memory, and then fail horribly (who the fuck thought "let's pseudorandomly pick a random process and KILL IT" was in any way sane!?) when it turns out there actually isn't enough. Windows actually checks that you're allocating a sane and available amount.

VirtualAlloc MEM_RESERVE 1099512676352 bytes failed: The paging file is too small for this operation to complete.

If you think the system should give you ONE FUCKING TERABYTE if there is nowhere near that amount of memory available on the system, you are an absolute idiot.

Even the Linux guys admit that it's stupid:

http://lwn.net/Articles/104179/

64-bit has its problems, but broken memory management is a bigger problem.