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

>>25

There was already mentioned a clear and simple usecase: a memory manager that needs to maintain a certain structure of the program's address space

Invalid use-case. Find a different way.

reserve a petabyte of memory

NO!!!

then try to determine how much memory you can reserve experimentally, with binary search

NO NO NO NO NO NO!!!

This is why programs are bloody bloated pieces of shit. Being greedy with memory benefits no one, not even yourself.

The right way to do it: reserve exactly what you need and use it all.

>>28

flying cars

Most of the population has enough problems driving a car with 2 dimensions to worry about. No thank you.

>>29
If they think they can ask for more memory than exists, even if they're never going to use it all, and they want such an insane request to succeed, then they're relying on overcommit.

It's not at all difficult to dynamically increase the size of the heap area while keeping its virtual extent contiguous.

True. But that's an entirely different matter.