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

So the existing implementation of HEAP_ALLOCED() for 64-bit machines used a cache. The fallback path for a cache miss needs to consult the actual memory mapping, which requires a lock.

In our application, which has quite large memory requirements and uses a lot of cores, there were a lot of cache misses, and contention for this lock was extremely high.

Fortunately, a solution to this problem had been sitting around for a while, in the form of the two-step allocator (the patch is by Giovanni Campagna, with a few updates by me). Instead of allocating memory randomly around the address space, the runtime reserves a large chunk of address space up front, and then allocates memory within that chunk. This works on certain OSs - Linux and OS X, but not Windows, it turns out.

Bringing in this patch made a huge difference to GC performance, although it’s difficult to get an accurate measure of how much, because the amount of contention for the lock in the old code depended on the random location of memory in the address space. In total the patches mentioned so far approximately halved GC overhead for our workload.

I liked Nintendo 64

I think you mean: Another reason GC is shit.

>>5
No, I mean "64bit vs 32bit means 256MB vs 4KB and a 2x slowdown of GC".

>>6
so don't use a GC, problem solved.

>>1
Limit your programs to 32 bit then.

kill x86

Another reason non-segmented memory is shit.
This "collection of megabytes" sounds like another name for segments.

For every pointer it sees, the GC asks the question “is this a pointer into the heap?”

Everything is either a pointer into the universal heap or it's not a valid segment.

Why doesn't it just allocate from the heap and store the pointer. Why would a bitmap of pieces of data be needed if the GC will never deallocate only part of the returned memory of the heap. In other words, why is that shitty GC testing if every pointer is valid? The hardware/OS already deals with the dynamically allocated memory via the virtual address tables.

Another reason Windows is shit.

On all other platforms of consequence, the allocator can just request that the entire zone of memory that is managed by the GC be taken from some contiguous address range (Linux even permits one to specify the placement of the range, where possible!) Then, the ownership of a pointer can determined by simple arithmetic comparison.

>>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.

>>13
MEM_RESERVE doesn't prevent overcommit. It doesn't actually allocate any physical memory.

OTOH there should be nothing preventing GHC to use MEM_RESERVE to reserve heap address space in gigabyte chunks, then MEM_COMMIT in megabyte-sized blocks as needed.

>>1 32bit sucks too, compared to 16bit master race. Mo memory mo problems, my african american!

>>13
New versions of linux try to return NULL on malloc in case memory is lacking.

>>14
No memory - no cry.

Windows is already being generous by allowing some soft-fail behaviour with growing out of physical memory and into the pagefile. Attempting to allocate 1TB at once on anything but a supercomputer is ridiculous no matter how you look at it, and any OS that allows this is just being retardedly deceptive.

>>14
If you "reserve" something, anyone sane will implicitly understand that you intend to use it in the future. How does attempting to reserve more memory than is available both in RAM and the pagefile combined on a typical system even make sense? It's impossible to ever satisfy such a request, so the OS rightly refuses to do it. This isn't overcommit where the (horrible) assumption is that there might be more memory in the future freed up; there will never be enough.

>>13

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

Or perhaps he's wondering why someone would shoot a man, before throwing him out of a plane?

64 bit should have broken compatibility with 32 bit. 32 bit programs should have to be emulated extremely slowly. It would have forced idiot appers to get with the latest fucking century and start moving to 64 bits.

Same with IPv6.

>>20
Retard.

>>20
Son, they shouldn't have made a 64-bit x86 at all, no matter how fast or slow. It's like unpolishing a turd after IA-32 polished it so well.

>>21
x86 is shit

>>22
I don't disagree with you: it was bad enough that they hacked up a perfectly good 16 bit x86 to get 32 bit x86 (but Intel at least tried to move away, until AMD fucked everything up); but I wasn't being specific to x86.

>>18

If you "reserve" something, anyone sane will implicitly understand that you intend to use it in the future. How does attempting to reserve more memory than is available both in RAM and the pagefile combined on a typical system even make sense?

Spoken like a right apper. I solemnly pledge to read your name as "see-udder" henceforth.

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.

The right way to do it: reserve a petabyte of memory for each arena you might need, then commit memory as it is actually allocated.

The wrong way to do it: have the OS refuse to reserve that much memory because it knows better, then try to determine how much memory you can reserve experimentally, with binary search. And you must know how many arenas you'll need in advance.

What makes it especially retarded is that the entire point of the overcommit hack is to allow management of your own address space (that shouldn't concern the OS in the slightest) separate from allocating virtual memory, which is exactly what the reserve/commit distinction does cleanly.

>>24
x86-64 is a 64 bit hack to a 32 bit hack of a 16 bit hack for a 8 bit processor of 4 bit hacks, hacked together by a 2 bit hack that can't stand 1 bit of hack.

2015

> using a simplistic cache backed by linear search, instead of a hash table

>>27
80's hardware could take care of that, but the 80's are still 50 years away because of the braindead retardation of x86 and Unix. Maybe we'll have GC in hardware the same time we have Rosie the Robot and flying cars.

>>13
Why do you assume overcommit is needed here? It's not at all difficult to dynamically increase the size of the heap area while keeping its virtual extent contiguous.

>>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.

>>27
epic 2015 meme /g/ro ;)

>>30

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

Finally someone with some sense around here.

>>32
And that would be Cudder?

>>32
Calculating the dynamic memory requirements of arbitrary programs is hard. You will not get anywhere trying to convince more than maybe 5% of all programmers that the effort is worthwhile, and most of those will need little convincing because they are working in a space or time limited environment that forces the issue. The other 95% probably can't meet their deadlines without ample guesswork, expandable hardware, and a forgiving runtime system.

>>34
Which is why you don't calculate them for "arbitrary programs", you calculate them for the one program you're currently writing.

>>35
Requirements for user facing applications change so often, it's impossible to think in terms of writing one program. No customer wants to hear that you need time to rethink your memory management scheme every time they ask you to change something.

>>30

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

Are you fucking retarded? Reserving a part of your address space is not being greedy with memory because it doesn't actually use any memory.

>>36
Why is the customer not charged penalties for changing requirements after system analysis? I understand if you develop a prototype system that wildly changes during system analysis. However, your system should not be changing drastically when you've committed to a set of specifications to deliver. Are you working for in-house software development where the boss (who doesn't understand the cost of changing requirements) commands a change in specification?

>>37
If you reserve memory, the system rightly expects you to use it, and since memory is finite, there is less memory available for others to reserve.

>>39

If you reserve memory, the system rightly expects you to use it, and since memory is finite, there is less memory available for others to reserve.

Are you really that stupid or are you pretending?

Again, there are two, count 'em Hans, TWO different things you want to do with memory: first is managing your own process's address space layout, second is mapping some of your address space to actually usable memory.

The whole overcommit bullshit came into being because UNIX only provides one way to ask for memory (except for that whateverbrk thing, it's not different), but people realized that the first need is real too, so they made a hack: you can malloc whatever you want to get a neat contiguous range of memory reserved, and only when you actually access some part of it that part is committed as a mapping to the OS-managed virtual memory.

One of the reasons Windows is faster than Linux or other Unices is that they learned from their mistakes and gave you two separate tools, one for managing your address space, another for asking the OS to actually allocate some memory in your address space.

Now the funniest thing, Si Udder, is that you don't know how to call VirtualAlloc:

int main(int argc, char ** argv)
{
SIZE_T size = 2000i64 * 1000 * 1000 * 1000;
auto mem = VirtualAlloc(nullptr, size, MEM_RESERVE, PAGE_READWRITE);
printf("%Iu %p\n", size, mem);
return 0;
}

Totes allocates 2 petabytes of address space on my Windows 7. But not four for some reason, idk why, it doesn't seem to like any kind of obvious limit (40-bit real addressing should prevent even 1 petabyte, 48 should accommodate 4 petabytes, probs some Windows thing).