4 ms·

What is the crash rate improvement all about? I get the address randomization, but what changes in 64 that fixed crashes?

gruez 9y ago
tab hoarding = hundreds of tabs = more than 3GB memory used = crash (max userspace memory with large address space aware is 3GB)
- cpeterso 9y ago
  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.
- LukeShu 9y ago
  Unless I'm mistaken, the limit for 32-bit processes on 64-bit Windows is actually 4GB; the 3GB limit is when running on 32-bit Windows. https://msdn.microsoft.com/en-us/library/aa366778.aspx https://msdn.microsoft.com/en-us/library/aa366778.aspx
  - user5994461 9y ago
    Only 2 to 3 GB are usable by the application, out of the 4GB addressable space. The rest is reserved.
    - deleted 9y ago
      [deleted]
    - LukeShu 9y ago
      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. https://msdn.microsoft.com/en-us/library/aa384271.aspx https://msdn.microsoft.com/en-us/library/aa384271.aspx https://msdn.microsoft.com/en-us/library/aa366778.aspx https://msdn.microsoft.com/en-us/library/aa366778.aspx
      - cpeterso 9y ago
        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. :)
        user5994461 9y ago
        >> 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.
        the8472 9y ago
        win64 FF has been built with LARGEADDRESSAWARE for the last 7 years. https://bugzilla.mozilla.org/show_bug.cgi?id=556382#c28 https://bugzilla.mozilla.org/show_bug.cgi?id=556382#c28
deleted 9y ago
[deleted]
__s 9y ago
They frame it as '64 bit users with more than 4GB RAM' so a lot of those are OOM related. More discussion @ https://groups.google.com/forum/#!topic/mozilla.dev.platform/hlCGG_Hib1w https://groups.google.com/forum/#!topic/mozilla.dev.platform...
- deleted 9y ago
  [deleted]
DiThi 9y ago
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.
- PrimHelios 9y ago
  Is there any reason it needs to be a contiguous block of memory?
  - gfodor 9y ago
    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.
  - DiThi 9y ago
    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.
  - Const-me 9y ago
    Legacy code and development time. 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.
the8472 9y ago
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.

gruez 9y ago

tab hoarding = hundreds of tabs = more than 3GB memory used = crash (max userspace memory with large address space aware is 3GB)

cpeterso 9y ago
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.
LukeShu 9y ago
Unless I'm mistaken, the limit for 32-bit processes on 64-bit Windows is actually 4GB; the 3GB limit is when running on 32-bit Windows. https://msdn.microsoft.com/en-us/library/aa366778.aspx https://msdn.microsoft.com/en-us/library/aa366778.aspx
- user5994461 9y ago
  Only 2 to 3 GB are usable by the application, out of the 4GB addressable space. The rest is reserved.
  - deleted 9y ago
    [deleted]
  - LukeShu 9y ago
    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. https://msdn.microsoft.com/en-us/library/aa384271.aspx https://msdn.microsoft.com/en-us/library/aa384271.aspx https://msdn.microsoft.com/en-us/library/aa366778.aspx https://msdn.microsoft.com/en-us/library/aa366778.aspx
    - cpeterso 9y ago
      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. :)
      - user5994461 9y ago
        >> 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.
      - the8472 9y ago
        win64 FF has been built with LARGEADDRESSAWARE for the last 7 years. https://bugzilla.mozilla.org/show_bug.cgi?id=556382#c28 https://bugzilla.mozilla.org/show_bug.cgi?id=556382#c28

deleted 9y ago

[deleted]

__s 9y ago

They frame it as '64 bit users with more than 4GB RAM' so a lot of those are OOM related. More discussion @ https://groups.google.com/forum/#!topic/mozilla.dev.platform/hlCGG_Hib1w https://groups.google.com/forum/#!topic/mozilla.dev.platform...

deleted 9y ago
[deleted]

DiThi 9y ago

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.

PrimHelios 9y ago
Is there any reason it needs to be a contiguous block of memory?
- gfodor 9y ago
  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.
- DiThi 9y ago
  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.
- Const-me 9y ago
  Legacy code and development time. 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.

the8472 9y ago

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.