Open Bug 1771231 Opened 3 years ago Updated 5 months ago

Proposal: move all 32-bit Firefox users on Windows 64-bit systems to 64-bit Firefox via updates.

Categories

(Toolkit :: Application Update, task, P3)

Desktop
Windows
task

Tracking

()

People

(Reporter: mhoye, Assigned: mconca)

References

Details

In the past, we have automatically upgraded 32-bit Firefoxes on 64 bit Windows machines to 64-bit FF, but only if the machine had more than some limited amount of physical RAM (2GB?)

Presently, some large percentage of Firefox users are still running 32 bit FF on 64 bit Windows, and they suffer a variety of unpleasantries including OOM-crashing more often as well as some variety of other non-crashing faults and performance issues.

I propose that we migrate all users on 64-bit Windows installations to 64-bit Firefox.

Assignee: nobody → mconca
Summary: Proposal: move all 32-bit Firefox users on eligible 64-bit systems to 64-bit Firefox via updates. → Proposal: move all 32-bit Firefox users on Windows 64-bit systems to 64-bit Firefox via updates.

For historical information about our first migration of 32-bit Firefox users to 64-bit (in Firefox 56 in 2017), see this wiki:

https://wiki.mozilla.org/Firefox/Win64

At that time, we only upgraded users with strictly more than 2 GB RAM (so 3 GB was effectively the minimum memory requirement) and added a registry key to allow users to opt-out of the migration. For users with less than 4 GB of physical memory, there is a trade-off between the larger virtual address space and the overhead of 64-bit code. We should probably confirm how many 32-bit Firefox users we have on 64-bit Windows and how many of them have less 3 GB RAM. 2 GB RAM is Microsoft's minimum memory requirement for Windows 7 and 10.

Given the security and stability benefits of a 64-bit address space in 2022, we should probably migrate all users on 64-bit Windows, regardless of how much RAM they have, and not bother with an opt-out registry key. If a user insists that want to run 32-bit Firefox, they can re-install 32-bit after the 64-bit migration.

At the time, the migration required a watershed release. I don't if that would still be required or if Releng has a watershed release planned for 2022 that this migration can piggyback on.

(In reply to Chris Peterson [:cpeterson] from comment #1)

For historical information about our first migration of 32-bit Firefox users to 64-bit (in Firefox 56 in 2017), see this wiki:

https://wiki.mozilla.org/Firefox/Win64

At that time, we only upgraded users with strictly more than 2 GB RAM (so 3 GB was effectively the minimum memory requirement) and added a registry key to allow users to opt-out of the migration. For users with less than 4 GB of physical memory, there is a trade-off between the larger virtual address space and the overhead of 64-bit code. We should probably confirm how many 32-bit Firefox users we have on 64-bit Windows and how many of them have less 3 GB RAM. 2 GB RAM is Microsoft's minimum memory requirement for Windows 7 and 10.

Given the security and stability benefits of a 64-bit address space in 2022, we should probably migrate all users on 64-bit Windows, regardless of how much RAM they have, and not bother with an opt-out registry key. If a user insists that want to run 32-bit Firefox, they can re-install 32-bit after the 64-bit migration.

At the time, the migration required a watershed release. I don't if that would still be required or if Releng has a watershed release planned for 2022 that this migration can piggyback on.

I think this should be doable without a watershed if it's a permanent change for all users. Balrog has alias that map the WoW64 build target to either 32-bit or 64-bit builds (currently 32-bit). If I understand correctly, we'd just need to change that mapping going forward.

Adding a couple of RelEng folks for their opinion.

Flags: needinfo?(jcristau)
Flags: needinfo?(gbrown)

Agreed - this doesn't sound too difficult. Happy to help if I can.

Flags: needinfo?(gbrown)

P3 since this is in the planning stage without definitive schedule.

Priority: -- → P3

If a user insists that want to run 32-bit Firefox, they can re-install 32-bit after the 64-bit migration.

This part requires either the opt-out registry key or a watershed, otherwise they'll keep getting updated to 64-bit, AIUI?

Flags: needinfo?(jcristau)

(In reply to Julien Cristau [:jcristau] from comment #5)

If a user insists that want to run 32-bit Firefox, they can re-install 32-bit after the 64-bit migration.

This part requires either the opt-out registry key or a watershed, otherwise they'll keep getting updated to 64-bit, AIUI?

If we want to maintain that, agreed. I was working on the assumption that we'd drop that requirement (which...has not been explicitly stated!).

I think it's safe to assume that outside of managed environments the number of people who have 64-bit-capable machines, but intentionally want to keep using 32-bit Firefox, is close enough to zero to make no difference.

MConca, I see you're out at the moment, but when you're back I'd like to bring this to your attention.

Elsewhere, CPeterson has remarked that "In my research last year of Fission crashes, I saw that a surprising number of Firefox users on 64-bit Windows are still using 32-bit Firefox builds. These users make up 10% of non-OOM crashes on 64-bit Windows, but 20% of OOMs on 64-bit Windows. Upgrading them to 64-bit builds would be an easy way to reduce those users' OOM rate by half" so at a glance this looks to a low risk investment of a modest amount of effort with a pretty compelling return.

Flags: needinfo?(mconca)

(In reply to Mike Hoye [:mhoye] from comment #8)

Upgrading them to 64-bit builds would be an easy way to reduce those users' OOM rate by half

I don't know that we can quite say that. Assuming that those users are crashing due to lack of address space rather than memory space, that might be true. But comparing the number of OOMs on 32-bit Firefox to the number on 64-bit Firefox is probably inviting a large sampling bias since those are probably the users with the smallest amounts of RAM.

Thanks mhoye. I'm picking this up as part of 2022 H2 product planning. We'll take a look at this and see if it makes sense.

Flags: needinfo?(mconca)

I haven't run Windows in a while, but I know that 32bit program directories were previously placed in a separate (x86) folder - if Firefox currently uses this directory on 32bit installs, the profile-per-install functionality may make it more cumbersome to move back to a 32bit install, and people may find their data to be inaccessible.

Just throwing that out there as an existing downside of profiles-per-installs and a potential issue if this moves forward.

(In reply to Asif Youssuff from comment #11)

I haven't run Windows in a while, but I know that 32bit program directories were previously placed in a separate (x86) folder - if Firefox currently uses this directory on 32bit installs, the profile-per-install functionality may make it more cumbersome to move back to a 32bit install, and people may find their data to be inaccessible.

There's nothing special about Windows' "C:\Program Files" or "C:\Program Files (x86)". You can install 32-bit or 64-bit programs in either directory.

When 32-bit Firefox is upgraded to 64-bit, we can overwrite the 32-bit .exe and .dll files in "C:\Program Files (x86)" with the 64-bit versions. That way we won't break any application shortcuts or Registry paths that may be pointing to the Firefox files in "C:\Program Files (x86)". They will all point to the new 64-bit files and continue to work.

Indeed, the Windows installer for thunderbird 64bit simply installs over the current 32bit location to avoid the per-profile-install issue - regardless of the root directory - and it has worked out fine.

See Also: → 1556748

What exactly is preventing all 64 bit capable Firefox or Thunderbird installations from automatically choosing to update to use 64 bit going forward?

(In reply to Worcester12345 from comment #14)

What exactly is preventing all 64 bit capable Firefox or Thunderbird installations from automatically choosing to update to use 64 bit going forward?

We don't have the ability in our update system to present this as a choice to the user. Update choices are made by us, on the server side. (This capability could be built, of course, but I do not think we would do so for such a highly technical decision.)

In our original view when we first did this migration, the way users could choose their architecture was through the installer. An explicit choice of 64-bit would (and will) always keep you on 64-bit Firefox. The same is currently true for 32-bit Firefox (although we're revisiting that decision here 32-bit users running on 64-bit Windows.) The main wrinkle to this is that our default installer automatically chooses 32-bit Firefox for 64-bit Windows users with low memory -- but that's also something we're revisiting here.

Depends on: win64-migration
See Also: → 1541292

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #15)
...

In our original view when we first did this migration, the way users could choose their architecture was through the installer.

This is what I meant here.

An explicit choice of 64-bit would (and will) always keep you on 64-bit Firefox. The same is currently true for 32-bit Firefox (although we're revisiting that decision here 32-bit users running on 64-bit Windows.)

What was the outcome of that "revisiting"?

The main wrinkle to this is that our default installer automatically chooses 32-bit Firefox for 64-bit Windows users with low memory -- but that's also something we're revisiting here.

Yes, I thought that was an issue, which would work better with 64/64, even if lower memory.

You need to log in before you can comment on or make changes to this bug.