On 2017-08-06 11:26 PM, Henri Sivonen wrote:
On Thu, Jul 20, 2017 at 10:42 AM, Chris Peterson<cpeter...@mozilla.com>  wrote:
Users with only 2 GB and 5 minute browser sessions would probably have a
faster user experience with 32-bit Firefox than with 64-bit, but how do we
weigh that experience versus the security benefits of ASLR?
Not giving users a security mechanism due to a non-obvious reason
feels bad. Furthermore, considering that Microsoft documents 2 GB as a
"requirement" for 64-bit Windows, is it really worthwhile for us to
treat three Windows pointer size combinations (32-bit on 32-bit,
64-bit on 64-bit and 32-bit on 64-bit) as fully supported when one of
the combinations is in contradiction with the OS vendor's stated

Do we have any metrics on whether 32-bit on 64-bit exhibits bugs that
32-bit on 32-bit and 64-bit on 64-bit don't? That is, what kind of bug
burden are we keeping by catering to users who've installed 64-bit
Windows with less than 2 GB of RAM in contradiction with what
Microsoft states as a requirement?

That's a fair question. 32-bit applications can only access 2 GB of virtual address space on Win32 OS, but can access 4 GB on Win64 OS. So in theory, some 32-bit pointer bugs could manifest differently on Win64 and Win32.

Do we test 32-bit Firefox on Win32 or Win64 today? I know we build 32-bit Firefox on Win64. Since more people will run 32-bit Firefox on Win32 than on Win64, we should probably test on Win32 or at least test on Win64 configured to only allow Firefox access to 2 GB of virtual address space.

In our experiments with Win64 OS users, users with 2 GB or less had slightly worse retention and crash rates when running 64-bit Firefox than 32-bit Firefox.

About 8% of Win64 users in our experiment had 2 GB or less, so we are talking about choosing a worse user experience for a fair number of people. (We didn't break out how many users had strictly less than 2 GB.) 64-bit Chrome's minimum memory requirement is 4 GB, so Google has similarly decided that supporting 32-bit on Win64 is worth the trouble.
dev-platform mailing list

Reply via email to