The limited address space combined with fragmentation due to a non-compactable heap allocations (C/C++) can lead to unsatisfiable allocations long before you actually hit the 4GB limit. And many allocations are not fallible, which means the browser has to OOM-crash if they cannot be satisfied.
To add to what it has been said, some asm.js based scripts (like games) need a relatively big (say, 128-256 mb) and aligned chunk of memory that is frequently not available on 32 bit machines even though there's a lot of free memory.
It's much simpler and much faster to make a chunk of code completely isolated in user space by masking the addresses it reads/writes to. For example, masking with 0xFFFF is the same as doing modulo 16. Add another bit to the mask and you're doing modulo 32, and so on. That's why I think the block must be not only contiguous, but also aligned. I may be wrong about the alignment now that I think about it. But the contiguous part is clear.
When I write C++ code that deals with large datasets, I try to avoid large continuous buffers as much as possible.
For cache locality, an aligned 1GB buffer is practically the same as a set of 64 aligned continuous buffers, 16MB/each. You’ll only hit RAM latency when crossing the boundary between the buffers, i.e. only 63 times through the whole 1GB of data.
One problem is std::vector. The standard says the whole vector must be continuous, i.e. to split large buffer into smaller chunks, one needs to implement a custom container on top of that.
Apparently, authors of C++ think the problem will go away by itself, with the switch to 64-bit platforms.
The problem does go away because of how addressing works. If you read my other comment, the address is masked for fast and safe sandboxing. If you have a huge virtual address space, it's practically guaranteed you'll have a contiguous chunk even when the actual memory is very fragmented.
For one thing, modern game engines often have custom allocators and a large array of performance critical bits of code that assume cache locality. So in general, having the memory involved be non-contigous could break lots of assumptions.
On 32-bit Windows, sure; because the process has to share its 4GB virtual address space with the system (the system getting the upper 1GB/2GB, depending on if 4GT is on). But it is my understanding that on 64-bit Windows, 32-bit processes do not have to share any of their 4GB virtual address space with the system, and can use the entire 4GB.
Though as noted in your MSDN link, 32-bit Windows application must use the IMAGE_FILE_LARGE_ADDRESS_AWARE linker flag to opt into a full 4GB virtual address space when running on 64-bit Windows OS. 32-bit applications that were only tested on a 32-bit OS might break if they see pointers above 0x80000000 so, in the name of backwards compatibility, Microsoft wisely kept the 2GB default. :)
>> 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared (default)
>> 4 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE set
While we are at it. The flag is a bit in the header of the .exe file. It should be set at compile time in the visual studio option, but it can be set into any file really with an hex editor.
Don't expect to be able to use the 4 GB even with the flag. There is a lower hard cap that depends on the version of windows.
Yes, out-of-virtual-memory crashes (OOM) are, in theory, no longer possible with 64-bit applications. We still do see some OOM crashes from 64-bit Firefox users.
32-bit applications on 64-bit Windows can access a full 4GB virtual address space (if they are compiled with a special linker flag) without needing the 3GB Windows boot-time flag.
