Firefox 64-bit for Windows 7

A couple weeks ago, I reached out to you all for input regarding making
Firefox 64-bit for Windows a supported product.  This is my attempt to
synthesize what you all shared here and in other places.

If I've got things terribly wrong, or omitted something important,
please let me know. After a hopefully short period of waiting for new
information and gathering some additional data, I will be following up
again with the Product team's proposal on what to do regarding Firefox
on win64.


• With a larger virtual address space, people using a 64-bit Firefox on
64-bit Windows could see fewer out of memory crashes (actually,
out-of-virtual-address-space crashes.)

•• This is not necessarily a clear win because 64-bit builds will use
more memory overall and we do not have a clear picture of Firefox's
address space usage in the wild, and what fraction of it is memory-backed.

•• To make any kind of estimates about stability improvements that could
come from a 64-bit Firefox, we need to understand more about the RAM
available on our 64-bit Windows users' systems and how much of Firefox's
usage is backed by memory and how much is mmaped files.

•• We can try to get that data from Telemetry (probes for about:memory)
and from our current crash data.


• With more registers and always available SSE2, performance could be
better for some things. There's quite a bit of debate here and we need
real measurement to say anything for certain. There are some Gecko
"layout" opportunities and some JS JIT opportunities but neither are
obviously big wins "for free".

•• 64-bit could offer gains for software rendering of features like
WebGL. This is because SSE2 is always available in 64-bit. (We currently
only support WebGL for ~40% of our users because it's dependent on
hardware rendering.) But SSE2 isn't enough, alone, to get the big gains
we'd want here. Those would require code changes which we have yet to do
like SIMD work.

•• We can make the 64-bit jitcode equal to or better than the 32-bit
jitcode on Windows 7, if we are willing to limit JS to using < 2GB of
memory for objects, strings, and functions. If we are unwilling to
accept that limitation, it's less clear if there's a win there.


• We can provide a more Secure Firefox in 64-bits. The address space
layout can be randomized far more effectively when you have 264 address
space to work with.

• 64-bit Firefox will, in most cases, use more more memory than 32-bit
Firefox. For systems that have limited RAM, this could lead to more
OOMs, not less.

• Binary add-ons will be incompatible with 64-bit builds.  This will
affect various software which install 32-bit binary add-ons, such as AV
products, etc.

• Few NPAPI plug-ins are available in 64-bit and Windows offers no
solution for "universal binaries" so we can't easily mitigate this the
way we do with the 32-64 Mac binary.

• Applications which work by hooking DLLs into Firefox's address space
will no longer work with 64-bit versions.  The most important example of
this type of application are accessibility clients.

• User might be confused about which Firefox build to use, which Firefox
add-ons to use, which Accessibility clients to use, and which plug-ins
to use.

• Maintaining another build/port means more dev/build/test/qa
infrastructure and effort.

• Flash, Java, and Silverlight all have 64-bit Windows NPAPI plug-ins,
though at differing levels of completeness.

• About half of win7 users are on 64-bit versions. That may not sound
like much, but it's about 2X our Mac and Linux users combined.

• Competitively, IE9 64-bit build doesn't have a modern JS
implementation. Chrome does not support 64-bit on Windows or Mac.

• We don't have comparative stability and performance data between
32-bit and 64-bit Firefoxen on 64-bit and 32-bit Windows

> To make any kind of estimates about stability improvements that could come from a 64-bit Firefox, we need to understand more about the RAM available on our 64-bit Windows users' systems and how much of Firefox's usage is backed by memory and how much is mmaped files.

I'm curious why this is relevant. I assumed both contributed equally
to VM size, which is what is relevant for out-of-VM-space crashes.

> 64-bit could offer gains for software rendering of features like WebGL. This is because SSE2 is always available in 64-bit. (We currently only support WebGL for ~40% of our users because it's dependent on hardware rendering.) But SSE2 isn't enough, alone, to get the big gains we'd want here. Those would require code changes which we have yet to do like SIMD work.

Are you implying that with SSE2 available and some SIMD coding, we'd
be able to turn on WebGL for users without supported graphics cards?
That would be pretty cool, actually.

There may be other ways to get these SSE2 benefits (e.g. a stub
installer picking a 32-bit version with or without SSE2, or runtime
checks around the software rendering code).

>  We can make the 64-bit jitcode equal to or better than the 32-bit jitcode on Windows 7, if we are willing to limit JS to using < 2GB of memory for objects, strings, and functions. If we are unwilling to accept that limitation, it's less clear if there's a win there.

I guess we should look at our telemetry data to see how much memory JS
is using, when Firefox is "using lots of memory". If the answer is
"when Firefox is using lots of memory, most of it tends to be JS" then
this would be dropping the stability win of 64-bit :/

Could Firefox start in "fast, small" mode but discard/recompile all
the  JIT code if it needs to move into "slower, bigger" mode?

> 64-bit Firefox will, in most cases, use more more memory than 32-bit Firefox. For systems that have limited RAM, this could lead to more OOMs, not less.

You mean 64-bit systems with less than 4GB total of RAM and swap? That
sounds unlikely.

> Applications which work by hooking DLLs into Firefox's address space will no longer work with 64-bit versions.  The most important example of this type of application are accessibility clients.

Maybe we can work with NVDA (open source screen reader) to ensure it's possible?

> Flash, Java, and Silverlight all have 64-bit Windows NPAPI plug-ins, though at differing levels of completeness.

I guess it would be nice to have plugin discovery ironed out before
releasing a Firefox that's not compatible with already-installed
Flash.

> We don't have comparative stability and performance data between 32-bit and 64-bit Firefoxen on 64-bit and 32-bit Windows

Is Mac or Linux data useful at all here? (Or for estimating the memory
use difference, for that matter.)

On Sat 12 Nov 2011 12:57:45 PM PST, Jesse Ruderman wrote:
>> To make any kind of estimates about stability improvements that could come from a 64-bit Firefox, we need to understand more about the RAM available on our 64-bit Windows users' systems and how much of Firefox's usage is backed by memory and how much is mmaped files.
>
> I'm curious why this is relevant. I assumed both contributed equally
> to VM size, which is what is relevant for out-of-VM-space crashes.

Yeah, I think a later point needs to be expanded:

>> 64-bit Firefox will, in most cases, use more more memory than 32-bit Firefox. For systems that have limited RAM, this could lead to more OOMs, not less.
>
> You mean 64-bit systems with less than 4GB total of RAM and swap? That
> sounds unlikely.

Yes, I think this is a little off. 64-bit would use more memory, which
would not lead to OOMs (which happen due to VM space exhaustion), but
rather to swapping/thrashing/paging/whatever you call it on Windows.

Actually, this is two separate effects: first, 64-bit code uses up a
bit more memory than 32-bit code (bigger integers etc.) and second,
there's no longer a 4GB (well, 3GB or 2GB, depending on the
configuration) maximum cap on VM size. The first leads to more OOMs, as
Asa claimed, but as Jesse points out, 64-bit systems with less than 4GB
memory are probably uncommon. The second means that Firefox could keep
gobbling up memory where on 32-bit it would have already OOMed from VM
space exhaustion. This can result in long pauses (eg CC), hangs, and
overall system crappiness. In terms of perception, I'd almost prefer
the crash. Does Windows have a way of setting an artificial VM size
cap, a la Linux's ulimit? (I'd love if it could be per-tab or domain or
compartment or something, but that's a different question.)

> Could Firefox start in "fast, small" mode but discard/recompile all
> the  JIT code if it needs to move into "slower, bigger" mode?

Seems feasible to me. It seems similar to recompilations triggered by
type sets expanding. How complex it would be, or how large the benefits
would be, I've no clue.

2011/11/12 Jesse Ruderman <jrud...@gmail.com>:

>> To make any kind of estimates about stability improvements that could come from a 64-bit Firefox, we need to understand more about the RAM available on our 64-bit Windows users' systems and how much of Firefox's usage is backed by memory and how much is mmaped files.
>
> I'm curious why this is relevant. I assumed both contributed equally
> to VM size, which is what is relevant for out-of-VM-space crashes.
>

>> 64-bit could offer gains for software rendering of features like WebGL. This is because SSE2 is always available in 64-bit. (We currently only support WebGL for ~40% of our users because it's dependent on hardware rendering.) But SSE2 isn't enough, alone, to get the big gains we'd want here. Those would require code changes which we have yet to do like SIMD work.
>
> Are you implying that with SSE2 available and some SIMD coding, we'd
> be able to turn on WebGL for users without supported graphics cards?
> That would be pretty cool, actually.

There is that idea on the horizon, to use a software OpenGL renderer
to enable WebGL where we don't have GPU-hardware-accelerated OpenGL.

The main problem is of course that software OpenGL rendering is slow;
but this is exactly the kind of big number crunching task where 64bit
and SSE2 would help.

If one wants to get concrete measurement, build a given fast software
OpenGL renderer in 32bit and in 64bit and compare the speed the two
versions give on some WebGL demo. A good example of a fast software
OpenGL renderer is Mesa3D's llvmpipe.
http://www.phoronix.com/scan.php?page=article&item=llvmpipe_summer_2011&num=1

Benoit

>
> There may be other ways to get these SSE2 benefits (e.g. a stub
> installer picking a 32-bit version with or without SSE2, or runtime
> checks around the software rendering code).
>
>>  We can make the 64-bit jitcode equal to or better than the 32-bit jitcode on Windows 7, if we are willing to limit JS to using < 2GB of memory for objects, strings, and functions. If we are unwilling to accept that limitation, it's less clear if there's a win there.
>
> I guess we should look at our telemetry data to see how much memory JS
> is using, when Firefox is "using lots of memory". If the answer is
> "when Firefox is using lots of memory, most of it tends to be JS" then
> this would be dropping the stability win of 64-bit :/
>

> Could Firefox start in "fast, small" mode but discard/recompile all
> the  JIT code if it needs to move into "slower, bigger" mode?
>

>> 64-bit Firefox will, in most cases, use more more memory than 32-bit Firefox. For systems that have limited RAM, this could lead to more OOMs, not less.
>
> You mean 64-bit systems with less than 4GB total of RAM and swap? That
> sounds unlikely.
>

>> Applications which work by hooking DLLs into Firefox's address space will no longer work with 64-bit versions.  The most important example of this type of application are accessibility clients.
>
> Maybe we can work with NVDA (open source screen reader) to ensure it's possible?
>
>> Flash, Java, and Silverlight all have 64-bit Windows NPAPI plug-ins, though at differing levels of completeness.
>
> I guess it would be nice to have plugin discovery ironed out before
> releasing a Firefox that's not compatible with already-installed
> Flash.
>
>> We don't have comparative stability and performance data between 32-bit and 64-bit Firefoxen on 64-bit and 32-bit Windows
>
> Is Mac or Linux data useful at all here? (Or for estimating the memory
> use difference, for that matter.)

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>

On Sun, Nov 13, 2011 at 7:57 AM, Jesse Ruderman <jrud...@gmail.com> wrote:
>
>>  We can make the 64-bit jitcode equal to or better than the 32-bit jitcode on Windows 7, if we are willing to limit JS to using < 2GB of memory for objects, strings, and functions. If we are unwilling to accept that limitation, it's less clear if there's a win there.
>
> I guess we should look at our telemetry data to see how much memory JS
> is using, when Firefox is "using lots of memory". If the answer is
> "when Firefox is using lots of memory, most of it tends to be JS" then
> this would be dropping the stability win of 64-bit :/

IIRC correctly this possible 2GB limit was not a global limit, but
per-compartment, which will eventually be per global object, so that's
not nearly as restrictive -- e.g. a single website wouldn't be able to
exceed 2GB, but JS across the whole browser certainly would.

Nick

sfink wrote:

> Yes, I think this is a little off. 64-bit would use more memory, which would not lead to OOMs (which
> happen due to VM space exhaustion), but rather to swapping/thrashing/paging/whatever you call it on
> Windows.

What happens if a program takes up more space than swap plus physical
memory?  I think Windows places an upper limit on the size of the swap
file and will kill you with OOM if it reaches the max size.

But it seems very unlikely to me that 64-bit would have more
memory-related crashes, because exhausting physical memory plus swap
should be a lot harder than exhausting 32-bit vaddr.

Asa Dotzler wrote:
> • With a larger virtual address space, people using a 64-bit Firefox
> on 64-bit Windows could see fewer out of memory crashes (actually,
> out-of-virtual-address-space crashes.)

We could get a very similar effect with a multi-process 32-bit Firefox. Each process would be limited to 2GB or 3GB but that would not be a significant limitation for quite a while, AFAICT.

Since we're developing "mobile first," we should be assuming 32-bit systems with less than 2GB of memory anyway.

> •• This is not necessarily a clear win because 64-bit builds will use
> more memory overall and we do not have a clear picture of Firefox's
> address space usage in the wild, and what fraction of it is
> memory-backed.

Similar things could be said about multi-process 32-bit Firefox.

> •• 64-bit could offer gains for software rendering of features like
> WebGL. This is because SSE2 is always available in 64-bit.

We don't need 64-bit for SSE2. The SSE2-based software WebGL renderer could be compiled to assume SSE2 is available, and then we could just disable that feature at runtime if SSE2 is not available. A 32-bit SSE2 software renderer would reach more users than a 64-bit one. (However, 64-bit registers might also be necessary for acceptable performance.)

> • We can provide a more Secure Firefox in 64-bits. The address space
> layout can be randomized far more effectively when you have 264
> address space to work with.

I would much rather have a multi-process 32-bit Firefox than a 64-bit single-process Firefox, as far as the security is concerned. AFAICT, sandboxing would be better for security than improved ASLR would be.

(Note that when I say "multi-process" I don't mean anything like the current e10s.)

- Brian

On 11/13/2011 4:14 AM, Brian Smith wrote:
> Asa Dotzler wrote:
>> • With a larger virtual address space, people using a 64-bit Firefox
>> on 64-bit Windows could see fewer out of memory crashes (actually,
>> out-of-virtual-address-space crashes.)
>
> We could get a very similar effect with a multi-process 32-bit Firefox. Each process would be limited to 2GB or 3GB but that would not be a significant limitation for quite a while, AFAICT.
>
> Since we're developing "mobile first," we should be assuming 32-bit systems with less than 2GB of memory anyway.
>

For how long?  With 64GB storage on the new iPhones, how long will it be
until they can handle several GB of RAM?

> For how long?  With 64GB storage on the new iPhones, how long will it be
> until they can handle several GB of RAM?

I'm not sure what you mean by "several GB", but not until ARM v8 will
we have 64-bit on mobile devices.  Engadget says we can expect
hardware around 2014.  Until then, we're constrained to 4GB at most.

http://www.engadget.com/2011/10/28/armv8-detailed-64-bit-architecture-appliedmicro-first-in-line/