Re: Updating 32-bit Windows users to 64-bit Windows builds?
I filed bug 1274659 [1] to track this proposal and attempted to summarize the issues brought up. Please add any technical comments and blocking bugs there. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1274659 -e On Fri, May 20, 2016 at 5:56 AM, Tobias B. Besemer < tobias.bese...@googlemail.com> wrote: > Am Freitag, 20. Mai 2016 01:48:24 UTC+2 schrieb Robert Strong: > > On Thu, May 19, 2016 at 3:18 PM, Tobias B. Besemer wrote: > > > > > Am Freitag, 13. Mai 2016 22:41:01 UTC+2 schrieb Benjamin Smedberg: > > > > We have considered this, but in the grand rollout plans for 64-bit > > > Firefox > > > > it's low on the list. We're still dealing with Flash > > > sandboxing/functional > > > > regressions as a blocker for wider rollout, and the next step is > probably > > > > to progressively roll out win64 to new users before we consider > anything > > > > for existing users. > > > > > > > > This will be much easier now that we have widevine and are dropping > > > > npapi/silverlight, but addon compat is also a concern and we wanted > to > > > > partly wait for webextensions before pushing more on this. > > > > > > > > --BDS > > > > > > Sounds like a plan for me! > > > Maybe there can be a ship of a installer that include 32bit & 64bit? > > > Or at least have one web-installer for both versions? > > > Also giving the user the change to make a easy upgrade from 32bit to > 64bit > > > with the offline-installer would be nice and a good test-drive for a > future > > > auto-update... > > > > > The installer does not equal auto-update. Two separate things entirely. > > Download size for a combined installer is not something we want to do to > > people on slow network connection but the auto selection via the stub > > installer is planned though no completion date yet due to other work > having > > priority. > > The idea was to test the upgrade from 32bit to 64bit first with the > offline installer because it should effect less people and would be maybe a > good test for all the routines/logic behind it like e.g. uninstall > something, moving files, or something like this... > > If not to much work, I would prefer to have one 32bit/64bit-installer for > people who don't know the difference... (as default download.) > Single Just-32bit/64bit-installer can persist for people who know for what > they have to looking for... (AFAICR other project did/do the same.) (At > least with just-English and multi-lang installers...) > > As I didn't knew how Mozilla will handle the switch... if - like by IE - > there will be 32bit/64bit parallel, or like Chrome do it, just one > version... I installed from each channel both version on my system and > created a bunch of icons for it, because the version overwrite ATM the > icons from each other... > I guess that a lot of people have the almost same scenario (both > versions), but by mistake and don't realize it! > So a routine (first in offline installer) in the 64bit version that check > if a (old) 32bit version exist too on the system and when, then de-install > it while install/update the 64bit version would be (IMHO) nice. > (Can test this and make QA.) > > Also I would like to see a error msg in future (or at least a big warning) > if a user try to use the 32bit installer on a 64bit system. > > AFAIK there is also no MozillaMaintenanceService as 64bit now... > > ...and the MozillaMaintenanceService should also block to install a 32bit > version on a 64bit Win (even normally no-one use this installer manual) and > uninstall 32bit if 64bit gets installed or updated. > > A long open wish from me (and I guess others, too) would be to see in > future a multi-lang web-installer. Should also make things easier... > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
Am Freitag, 20. Mai 2016 01:48:24 UTC+2 schrieb Robert Strong: > On Thu, May 19, 2016 at 3:18 PM, Tobias B. Besemer wrote: > > > Am Freitag, 13. Mai 2016 22:41:01 UTC+2 schrieb Benjamin Smedberg: > > > We have considered this, but in the grand rollout plans for 64-bit > > Firefox > > > it's low on the list. We're still dealing with Flash > > sandboxing/functional > > > regressions as a blocker for wider rollout, and the next step is probably > > > to progressively roll out win64 to new users before we consider anything > > > for existing users. > > > > > > This will be much easier now that we have widevine and are dropping > > > npapi/silverlight, but addon compat is also a concern and we wanted to > > > partly wait for webextensions before pushing more on this. > > > > > > --BDS > > > > Sounds like a plan for me! > > Maybe there can be a ship of a installer that include 32bit & 64bit? > > Or at least have one web-installer for both versions? > > Also giving the user the change to make a easy upgrade from 32bit to 64bit > > with the offline-installer would be nice and a good test-drive for a future > > auto-update... > > > The installer does not equal auto-update. Two separate things entirely. > Download size for a combined installer is not something we want to do to > people on slow network connection but the auto selection via the stub > installer is planned though no completion date yet due to other work having > priority. The idea was to test the upgrade from 32bit to 64bit first with the offline installer because it should effect less people and would be maybe a good test for all the routines/logic behind it like e.g. uninstall something, moving files, or something like this... If not to much work, I would prefer to have one 32bit/64bit-installer for people who don't know the difference... (as default download.) Single Just-32bit/64bit-installer can persist for people who know for what they have to looking for... (AFAICR other project did/do the same.) (At least with just-English and multi-lang installers...) As I didn't knew how Mozilla will handle the switch... if - like by IE - there will be 32bit/64bit parallel, or like Chrome do it, just one version... I installed from each channel both version on my system and created a bunch of icons for it, because the version overwrite ATM the icons from each other... I guess that a lot of people have the almost same scenario (both versions), but by mistake and don't realize it! So a routine (first in offline installer) in the 64bit version that check if a (old) 32bit version exist too on the system and when, then de-install it while install/update the 64bit version would be (IMHO) nice. (Can test this and make QA.) Also I would like to see a error msg in future (or at least a big warning) if a user try to use the 32bit installer on a 64bit system. AFAIK there is also no MozillaMaintenanceService as 64bit now... ...and the MozillaMaintenanceService should also block to install a 32bit version on a 64bit Win (even normally no-one use this installer manual) and uninstall 32bit if 64bit gets installed or updated. A long open wish from me (and I guess others, too) would be to see in future a multi-lang web-installer. Should also make things easier... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
On Thu, May 19, 2016 at 3:18 PM, Tobias B. Besemer < tobias.bese...@googlemail.com> wrote: > Am Freitag, 13. Mai 2016 22:41:01 UTC+2 schrieb Benjamin Smedberg: > > We have considered this, but in the grand rollout plans for 64-bit > Firefox > > it's low on the list. We're still dealing with Flash > sandboxing/functional > > regressions as a blocker for wider rollout, and the next step is probably > > to progressively roll out win64 to new users before we consider anything > > for existing users. > > > > This will be much easier now that we have widevine and are dropping > > npapi/silverlight, but addon compat is also a concern and we wanted to > > partly wait for webextensions before pushing more on this. > > > > --BDS > > Sounds like a plan for me! > Maybe there can be a ship of a installer that include 32bit & 64bit? > Or at least have one web-installer for both versions? > Also giving the user the change to make a easy upgrade from 32bit to 64bit > with the offline-installer would be nice and a good test-drive for a future > auto-update... > The installer does not equal auto-update. Two separate things entirely. Download size for a combined installer is not something we want to do to people on slow network connection but the auto selection via the stub installer is planned though no completion date yet due to other work having priority. > > > > On Thu, May 12, 2016 at 11:45 AM, Ted Mielczarek> wrote: > > > > > Hello, > > > > > > Given all the discussion around SSE[2] lately, I was curious as to > > > whether we had made any plans to update Windows users that are running > > > 32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows > > > builds. The 64-bit Windows builds do use SSE2, since that's a baseline > > > requirement for x86-64 processors, and the overall performance should > > > generally be better (modulo memory usage, I'm not sure if we have an > > > exact comparison). Additionally 64-bit builds are much less likely to > > > encounter OOM crashes due to address space fragmentation since they > have > > > a very large address space compared to the maximum 4GB available to the > > > 32-bit builds. > > > > > > It does seem like we'd need some minimal checking here, obviously first > > > for whether the user is running 64-bit Windows, but also possibly > > > whether they use 32-bit plugins (until such time as we unsupport > NPAPI). > > > 32-bit plugins will not work on a 64-bit Windows Firefox (we do not > have > > > the equivalent of Universal binaries like we do on OS X). > > > > > > -Ted > > > ___ > > > dev-platform mailing list > > > dev-platform@lists.mozilla.org > > > https://lists.mozilla.org/listinfo/dev-platform > > > > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
Am Freitag, 13. Mai 2016 22:41:01 UTC+2 schrieb Benjamin Smedberg: > We have considered this, but in the grand rollout plans for 64-bit Firefox > it's low on the list. We're still dealing with Flash sandboxing/functional > regressions as a blocker for wider rollout, and the next step is probably > to progressively roll out win64 to new users before we consider anything > for existing users. > > This will be much easier now that we have widevine and are dropping > npapi/silverlight, but addon compat is also a concern and we wanted to > partly wait for webextensions before pushing more on this. > > --BDS Sounds like a plan for me! Maybe there can be a ship of a installer that include 32bit & 64bit? Or at least have one web-installer for both versions? Also giving the user the change to make a easy upgrade from 32bit to 64bit with the offline-installer would be nice and a good test-drive for a future auto-update... > On Thu, May 12, 2016 at 11:45 AM, Ted Mielczarekwrote: > > > Hello, > > > > Given all the discussion around SSE[2] lately, I was curious as to > > whether we had made any plans to update Windows users that are running > > 32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows > > builds. The 64-bit Windows builds do use SSE2, since that's a baseline > > requirement for x86-64 processors, and the overall performance should > > generally be better (modulo memory usage, I'm not sure if we have an > > exact comparison). Additionally 64-bit builds are much less likely to > > encounter OOM crashes due to address space fragmentation since they have > > a very large address space compared to the maximum 4GB available to the > > 32-bit builds. > > > > It does seem like we'd need some minimal checking here, obviously first > > for whether the user is running 64-bit Windows, but also possibly > > whether they use 32-bit plugins (until such time as we unsupport NPAPI). > > 32-bit plugins will not work on a 64-bit Windows Firefox (we do not have > > the equivalent of Universal binaries like we do on OS X). > > > > -Ted > > ___ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
Am Freitag, 13. Mai 2016 14:35:52 UTC+2 schrieb Ben Hearsum: > On 2016-05-12 06:44 PM, khagar...@gmail.com wrote: > > On Thursday, May 12, 2016 at 11:47:15 PM UTC+2, Karl Tomlinson wrote: > >> Lawrence Mandel writes: > >> > >>> Do we need this criteria? > >>> > >>> RAM - Does it hurt to move an instance that has <4GB? > >> > >> Yes. OOM will be more common with 64-bit builds on systems with > >> less RAM because 64-bit builds use more memory. > > > > Quite the opposite actually. The overhead is negligible, but the stability > > improvement is tremendous. After switching to 64-bit I haven't crashed even > > once for several months, whereas on 32-bit I crashed several times a week. > > > > How much RAM do you have? 64-bit builds should use more memory than > 32-bit builds under the same circumstances. As others in this thread > have noted, this can lead to easier OOM crashes and slowness to due > additional swapping. If you have a bunch of RAM these downsides go away. After there get a lot of mem problems fixed in FF over the last months, FF use in general less mem then before! IMHO try to fix more mem-probs/-leaks should bring in general more and then you can forget get overhead. (* My experiences with monitoring the FF mem over the last ~2.5years.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
Am Freitag, 13. Mai 2016 10:34:59 UTC+2 schrieb bo...@mozilla.com: > On Thursday, 12 May 2016 21:36:53 UTC+1, Chris Peterson wrote: > > Yes. Flash and Silverlight both have 64-bit plugins that work in 64-bit > > Firefox. Streaming video services will likely move their Firefox users > > from Silverlight to Widevine this year, so Silverlight usage will > > decline by EOY. > > As Flash Player doesn't provide Protected Mode for 64-bit, we've enabled our > own sandbox. > Unfortunately this causes some regressions as the Flash DLL was never > designed to be sandboxed when run in process like this. We'd like to > strengthen the policy, but that breaks too many things. > > So, we'd have to think carefully before deciding who we could move. > > > On 5/12/16 1:10 PM, Ryan VanderMeulen wrote: > > > Flash installs the 32-bit and 64-bit plugin versions side by side > > > already (in System32 and SysWOW64, respectively), so I don't think > > > that's an issue here. > > Confusingly the 64-bit version lives in System32 and the 32-bit version in > SysWOW64. > This is Microsoft's confusion not Adobe's. > SysWOW64 generally contains files used for running 32-bit binaries on 64-bit > Windows (WOW64 is Windows [32-bit] On Windows 64[-bit]) > System32 is just a legacy naming hangover as I understand, because too many > application depended on it. system = 16-bit System32 = 32-bit SysWOW64 = 64-bit (Or I have no clue where else the 64-bit-dlls get stored...) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
Am Donnerstag, 12. Mai 2016 18:56:19 UTC+2 schrieb Ben Hearsum: > Do you have thoughts on how we'll be able to serve the users the correct > build if we have to base the decision on plugins they may have or other > information that's not in the update ping? We can already detect 32-bit > builds on 64-bit Windows through the build target, but information about > plugins or RAM is not something we know about when serving updates. Is it possible to find out from which plugins no 64bit version exist yet? So e.g. if the user have Flash 32bit the update can happen... like with extensions on startup a check and a (forced) update... AFAIK updates get always done without a check before if there exist a update for each extension... Is there really a plugin (vendor) that can be a reason to not update the browser to a newer (64bit) build? Btw.: AFAIK there is also no check about the compatibility of plugins before a normal update starts and if a plugin is un-secure, FF deactivate it, too. > > On 2016-05-12 11:45 AM, Ted Mielczarek wrote: > > Hello, > > > > Given all the discussion around SSE[2] lately, I was curious as to > > whether we had made any plans to update Windows users that are running > > 32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows > > builds. The 64-bit Windows builds do use SSE2, since that's a baseline > > requirement for x86-64 processors, and the overall performance should > > generally be better (modulo memory usage, I'm not sure if we have an > > exact comparison). Additionally 64-bit builds are much less likely to > > encounter OOM crashes due to address space fragmentation since they have > > a very large address space compared to the maximum 4GB available to the > > 32-bit builds. > > > > It does seem like we'd need some minimal checking here, obviously first > > for whether the user is running 64-bit Windows, but also possibly > > whether they use 32-bit plugins (until such time as we unsupport NPAPI). > > 32-bit plugins will not work on a 64-bit Windows Firefox (we do not have > > the equivalent of Universal binaries like we do on OS X). > > > > -Ted > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
Am Donnerstag, 12. Mai 2016 18:22:53 UTC+2 schrieb David Baron: > On Thursday 2016-05-12 11:45 -0400, Ted Mielczarek wrote: > > requirement for x86-64 processors, and the overall performance should > > generally be better (modulo memory usage, I'm not sure if we have an > > exact comparison). Additionally 64-bit builds are much less likely to > > encounter OOM crashes due to address space fragmentation since they have > > a very large address space compared to the maximum 4GB available to the > > 32-bit builds. > > Might it be worth considering automatically updating users on > machines with 6GB (roughly) or more of RAM, but leaving alone users > with less RAM? No! FF crashes at ~2.5GB used ram! Also AFAIK the mem can be used from the pagefile.sys... (even really slow!) So there should be no min. system limit for a OOM crash! > > -David > > -- > 턞 L. David Baron http://dbaron.org/ 턂 > 턢 Mozilla https://www.mozilla.org/ 턂 > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. >- Robert Frost, Mending Wall (1914) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
On Friday 2016-05-13 13:10 -0700, Andrew McCreight wrote: > On 64-bit systems, pointers take 8 bytes of memory instead of 4. A lot of > the contents of memory is pointers. Thus a 64-bit build consumes more > memory for a given workload. It isn't as bad as, say, twice as much memory, > but it is enough that if you are close to the limits of your system it > could cause problems. On the flip side, it does make sense that the point where 64-bit builds become better memory-wise than 32-bit builds could be substantially below 4GB of RAM, given that 32-bit builds can run out of memory due to fragmentation of the address space. Where the tradeoff lies is probably best determined by experiment. (There are also presumably some security improvements with 64-bit.) -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
We have considered this, but in the grand rollout plans for 64-bit Firefox it's low on the list. We're still dealing with Flash sandboxing/functional regressions as a blocker for wider rollout, and the next step is probably to progressively roll out win64 to new users before we consider anything for existing users. This will be much easier now that we have widevine and are dropping npapi/silverlight, but addon compat is also a concern and we wanted to partly wait for webextensions before pushing more on this. --BDS On Thu, May 12, 2016 at 11:45 AM, Ted Mielczarekwrote: > Hello, > > Given all the discussion around SSE[2] lately, I was curious as to > whether we had made any plans to update Windows users that are running > 32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows > builds. The 64-bit Windows builds do use SSE2, since that's a baseline > requirement for x86-64 processors, and the overall performance should > generally be better (modulo memory usage, I'm not sure if we have an > exact comparison). Additionally 64-bit builds are much less likely to > encounter OOM crashes due to address space fragmentation since they have > a very large address space compared to the maximum 4GB available to the > 32-bit builds. > > It does seem like we'd need some minimal checking here, obviously first > for whether the user is running 64-bit Windows, but also possibly > whether they use 32-bit plugins (until such time as we unsupport NPAPI). > 32-bit plugins will not work on a 64-bit Windows Firefox (we do not have > the equivalent of Universal binaries like we do on OS X). > > -Ted > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
On Fri, May 13, 2016 at 1:02 PM,wrote: > Why do you developers keep insisting breathlessly that 64-bit builds are > memory hogs? I'm a power user who has 3 windows and 1,565 tabs open. I have > a 4 GB laptop and a 16 GB desktop replaced a 6 GB desktop. I like to think > that I use Firefox close to its breaking point. On any given day, Firefox > takes between 2.4 GB and 3.1 GB no matter whether it was the 32-bit build > or is the 64-bit build. Only one time while I was using the 64-bit build > did I notice it climb on its own all the way up to 5.9 GB, but then the > memory was released and it settled down to 3.l GB again and, I repeat, that > was only ONE TIME. Microsoft has a 64-bit version of Edge that I use. Also, > I downloaded the 64-bit beta version of Google Chrome and use it with > little problem compared to its 32-bit version. Under what I consider normal > circumstances, I just don't see 64-bit versions eating memory like Mozilla > developers keep insisting they do. > On 64-bit systems, pointers take 8 bytes of memory instead of 4. A lot of the contents of memory is pointers. Thus a 64-bit build consumes more memory for a given workload. It isn't as bad as, say, twice as much memory, but it is enough that if you are close to the limits of your system it could cause problems. Andrew > > Now to be fair, I understand not wanting to put the 64-bit version of > Firefox on low memory systems. I left the 32-bit version on my 4 GB laptop. > I would personally say that x64 OS's with 6GB or more memory should be able > to be upgraded to the 64-bit version of Firefox. After NPAPI support goes > away, there really should be no excuse to leave such systems on the 32-bit > version as the 32-bit version doesn't take advantage of all of the 64-bit > OS features and 64-bit processor's features. And as I have said previously, > the 64-bit version is way more stable than the 32-bit version. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
On Friday, May 13, 2016 at 7:35:52 AM UTC-5, Ben Hearsum wrote: > On 2016-05-12 06:44 PM, khagar...@gmail.com wrote: > > On Thursday, May 12, 2016 at 11:47:15 PM UTC+2, Karl Tomlinson wrote: > >> Lawrence Mandel writes: > >> > >>> Do we need this criteria? > >>> > >>> RAM - Does it hurt to move an instance that has <4GB? > >> > >> Yes. OOM will be more common with 64-bit builds on systems with > >> less RAM because 64-bit builds use more memory. > > > > Quite the opposite actually. The overhead is negligible, but the stability > > improvement is tremendous. After switching to 64-bit I haven't crashed even > > once for several months, whereas on 32-bit I crashed several times a week. > > > > How much RAM do you have? 64-bit builds should use more memory than > 32-bit builds under the same circumstances. As others in this thread > have noted, this can lead to easier OOM crashes and slowness to due > additional swapping. If you have a bunch of RAM these downsides go away. Why do you developers keep insisting breathlessly that 64-bit builds are memory hogs? I'm a power user who has 3 windows and 1,565 tabs open. I have a 4 GB laptop and a 16 GB desktop replaced a 6 GB desktop. I like to think that I use Firefox close to its breaking point. On any given day, Firefox takes between 2.4 GB and 3.1 GB no matter whether it was the 32-bit build or is the 64-bit build. Only one time while I was using the 64-bit build did I notice it climb on its own all the way up to 5.9 GB, but then the memory was released and it settled down to 3.l GB again and, I repeat, that was only ONE TIME. Microsoft has a 64-bit version of Edge that I use. Also, I downloaded the 64-bit beta version of Google Chrome and use it with little problem compared to its 32-bit version. Under what I consider normal circumstances, I just don't see 64-bit versions eating memory like Mozilla developers keep insisting they do. Now to be fair, I understand not wanting to put the 64-bit version of Firefox on low memory systems. I left the 32-bit version on my 4 GB laptop. I would personally say that x64 OS's with 6GB or more memory should be able to be upgraded to the 64-bit version of Firefox. After NPAPI support goes away, there really should be no excuse to leave such systems on the 32-bit version as the 32-bit version doesn't take advantage of all of the 64-bit OS features and 64-bit processor's features. And as I have said previously, the 64-bit version is way more stable than the 32-bit version. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
On 2016-05-12 06:44 PM, khagar...@gmail.com wrote: On Thursday, May 12, 2016 at 11:47:15 PM UTC+2, Karl Tomlinson wrote: Lawrence Mandel writes: Do we need this criteria? RAM - Does it hurt to move an instance that has <4GB? Yes. OOM will be more common with 64-bit builds on systems with less RAM because 64-bit builds use more memory. Quite the opposite actually. The overhead is negligible, but the stability improvement is tremendous. After switching to 64-bit I haven't crashed even once for several months, whereas on 32-bit I crashed several times a week. How much RAM do you have? 64-bit builds should use more memory than 32-bit builds under the same circumstances. As others in this thread have noted, this can lead to easier OOM crashes and slowness to due additional swapping. If you have a bunch of RAM these downsides go away. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
On Thursday, May 12, 2016 at 5:44:32 PM UTC-5, khag...@gmail.com wrote: > On Thursday, May 12, 2016 at 11:47:15 PM UTC+2, Karl Tomlinson wrote: > > Lawrence Mandel writes: > > > > > Do we need this criteria? > > > > > > RAM - Does it hurt to move an instance that has <4GB? > > > > Yes. OOM will be more common with 64-bit builds on systems with > > less RAM because 64-bit builds use more memory. > > Quite the opposite actually. The overhead is negligible, but the stability > improvement is tremendous. After switching to 64-bit I haven't crashed even > once for several months, whereas on 32-bit I crashed several times a week. That's been my experience as well. I found out that Mozilla had started 64-bit versions for the beta channel, so I uninstalled my 32-bit version and installed the 64-bit version. I also use to have several OOM's a week with the 32-bit version and with the 64-bit version I have had none. The stability of the 64-bit version is impressive. Also, memory usage isn't all that different for me as well. As soon as Mozilla irons out all the critical bugs and end NPAPI support, it really should upgrade every one it thinks would benefit to the 64-bit version. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
On Thursday, 12 May 2016 21:36:53 UTC+1, Chris Peterson wrote: > Yes. Flash and Silverlight both have 64-bit plugins that work in 64-bit > Firefox. Streaming video services will likely move their Firefox users > from Silverlight to Widevine this year, so Silverlight usage will > decline by EOY. As Flash Player doesn't provide Protected Mode for 64-bit, we've enabled our own sandbox. Unfortunately this causes some regressions as the Flash DLL was never designed to be sandboxed when run in process like this. We'd like to strengthen the policy, but that breaks too many things. So, we'd have to think carefully before deciding who we could move. > On 5/12/16 1:10 PM, Ryan VanderMeulen wrote: > > Flash installs the 32-bit and 64-bit plugin versions side by side > > already (in System32 and SysWOW64, respectively), so I don't think > > that's an issue here. Confusingly the 64-bit version lives in System32 and the 32-bit version in SysWOW64. This is Microsoft's confusion not Adobe's. SysWOW64 generally contains files used for running 32-bit binaries on 64-bit Windows (WOW64 is Windows [32-bit] On Windows 64[-bit]) System32 is just a legacy naming hangover as I understand, because too many application depended on it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
On Thursday, May 12, 2016 at 11:47:15 PM UTC+2, Karl Tomlinson wrote: > Lawrence Mandel writes: > > > Do we need this criteria? > > > > RAM - Does it hurt to move an instance that has <4GB? > > Yes. OOM will be more common with 64-bit builds on systems with > less RAM because 64-bit builds use more memory. Quite the opposite actually. The overhead is negligible, but the stability improvement is tremendous. After switching to 64-bit I haven't crashed even once for several months, whereas on 32-bit I crashed several times a week. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
On Thursday 2016-05-12 15:33 -0700, Kyle Huey wrote: > On Thu, May 12, 2016 at 2:46 PM, Karl Tomlinsonwrote: > > > Lawrence Mandel writes: > > > > > Do we need this criteria? > > > > > > RAM - Does it hurt to move an instance that has <4GB? > > > > Yes. OOM will be more common with 64-bit builds on systems with > > less RAM because 64-bit builds use more memory. > > > > Our OOM crashes are almost always from running out of virtual memory, not > physical. However, running low on physical memory is (given the existence of swap) more likely to result in slowdowns and swapping, which are a different set of bad symptoms from crashes. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
On Thu, May 12, 2016 at 2:46 PM, Karl Tomlinsonwrote: > Lawrence Mandel writes: > > > Do we need this criteria? > > > > RAM - Does it hurt to move an instance that has <4GB? > > Yes. OOM will be more common with 64-bit builds on systems with > less RAM because 64-bit builds use more memory. > Our OOM crashes are almost always from running out of virtual memory, not physical. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
Last time I checked we saw something like a 35% increase in overhead on AWSY going from 32-bit to 64-bit Firefox on 64-bit Windows, so yes there is a significant impact. On the other hand you no-longer run into the OOM-because-of-address-space-exhaustion and OOM-because-we-can't-find-a-one-meg-chunk-in-this-horribly-fragmented-heap issues. In theory even if the physical memory usage gets too high we can hope that things get paged out rather than OOMing. So there's a reasonable argument for just upping everyone who can to 64-bit. -e On Thu, May 12, 2016 at 2:46 PM, Karl Tomlinsonwrote: > Lawrence Mandel writes: > > > Do we need this criteria? > > > > RAM - Does it hurt to move an instance that has <4GB? > > Yes. OOM will be more common with 64-bit builds on systems with > less RAM because 64-bit builds use more memory. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
Lawrence Mandel writes: > Do we need this criteria? > > RAM - Does it hurt to move an instance that has <4GB? Yes. OOM will be more common with 64-bit builds on systems with less RAM because 64-bit builds use more memory. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
Yes. Flash and Silverlight both have 64-bit plugins that work in 64-bit Firefox. Streaming video services will likely move their Firefox users from Silverlight to Widevine this year, so Silverlight usage will decline by EOY. On 5/12/16 1:10 PM, Ryan VanderMeulen wrote: Flash installs the 32-bit and 64-bit plugin versions side by side already (in System32 and SysWOW64, respectively), so I don't think that's an issue here. -Ryan On 5/12/2016 3:38 PM, Lawrence Mandel wrote: Do we need this criteria? RAM - Does it hurt to move an instance that has <4GB? NPAPI - We've announced that we'll remove support this year [1]. Should we just wait until we do? Do we have a solution for Flash on Win64 that makes this viable? Lawrence [1] https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/ On Thu, May 12, 2016 at 3:12 PM, Ben Hearsumwrote: This is a slight change from the current model where we purposely make the client very dumb, and make the decision on the server (to minimize the possibility of client-side bug making updates impossible). However, this doesn't seem like a case where we could get somebody stuck very easily, and I don't see a practical way of making the decision on the server if it requires this much information. On 2016-05-12 01:07 PM, Ted Mielczarek wrote: I suspect we'd want to add some extra token like "it's ok to update this 32-bit build to a 64-bit build", and have all the gating logic live on the client-side. Odds are if we want to change the criteria we'd have to change the client anyway. -Ted On Thu, May 12, 2016, at 12:56 PM, Ben Hearsum wrote: Do you have thoughts on how we'll be able to serve the users the correct build if we have to base the decision on plugins they may have or other information that's not in the update ping? We can already detect 32-bit builds on 64-bit Windows through the build target, but information about plugins or RAM is not something we know about when serving updates. On 2016-05-12 11:45 AM, Ted Mielczarek wrote: Hello, Given all the discussion around SSE[2] lately, I was curious as to whether we had made any plans to update Windows users that are running 32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows builds. The 64-bit Windows builds do use SSE2, since that's a baseline requirement for x86-64 processors, and the overall performance should generally be better (modulo memory usage, I'm not sure if we have an exact comparison). Additionally 64-bit builds are much less likely to encounter OOM crashes due to address space fragmentation since they have a very large address space compared to the maximum 4GB available to the 32-bit builds. It does seem like we'd need some minimal checking here, obviously first for whether the user is running 64-bit Windows, but also possibly whether they use 32-bit plugins (until such time as we unsupport NPAPI). 32-bit plugins will not work on a 64-bit Windows Firefox (we do not have the equivalent of Universal binaries like we do on OS X). -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
Flash installs the 32-bit and 64-bit plugin versions side by side already (in System32 and SysWOW64, respectively), so I don't think that's an issue here. -Ryan On 5/12/2016 3:38 PM, Lawrence Mandel wrote: Do we need this criteria? RAM - Does it hurt to move an instance that has <4GB? NPAPI - We've announced that we'll remove support this year [1]. Should we just wait until we do? Do we have a solution for Flash on Win64 that makes this viable? Lawrence [1] https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/ On Thu, May 12, 2016 at 3:12 PM, Ben Hearsumwrote: This is a slight change from the current model where we purposely make the client very dumb, and make the decision on the server (to minimize the possibility of client-side bug making updates impossible). However, this doesn't seem like a case where we could get somebody stuck very easily, and I don't see a practical way of making the decision on the server if it requires this much information. On 2016-05-12 01:07 PM, Ted Mielczarek wrote: I suspect we'd want to add some extra token like "it's ok to update this 32-bit build to a 64-bit build", and have all the gating logic live on the client-side. Odds are if we want to change the criteria we'd have to change the client anyway. -Ted On Thu, May 12, 2016, at 12:56 PM, Ben Hearsum wrote: Do you have thoughts on how we'll be able to serve the users the correct build if we have to base the decision on plugins they may have or other information that's not in the update ping? We can already detect 32-bit builds on 64-bit Windows through the build target, but information about plugins or RAM is not something we know about when serving updates. On 2016-05-12 11:45 AM, Ted Mielczarek wrote: Hello, Given all the discussion around SSE[2] lately, I was curious as to whether we had made any plans to update Windows users that are running 32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows builds. The 64-bit Windows builds do use SSE2, since that's a baseline requirement for x86-64 processors, and the overall performance should generally be better (modulo memory usage, I'm not sure if we have an exact comparison). Additionally 64-bit builds are much less likely to encounter OOM crashes due to address space fragmentation since they have a very large address space compared to the maximum 4GB available to the 32-bit builds. It does seem like we'd need some minimal checking here, obviously first for whether the user is running 64-bit Windows, but also possibly whether they use 32-bit plugins (until such time as we unsupport NPAPI). 32-bit plugins will not work on a 64-bit Windows Firefox (we do not have the equivalent of Universal binaries like we do on OS X). -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
Do we need this criteria? RAM - Does it hurt to move an instance that has <4GB? NPAPI - We've announced that we'll remove support this year [1]. Should we just wait until we do? Do we have a solution for Flash on Win64 that makes this viable? Lawrence [1] https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/ On Thu, May 12, 2016 at 3:12 PM, Ben Hearsumwrote: > This is a slight change from the current model where we purposely make the > client very dumb, and make the decision on the server (to minimize the > possibility of client-side bug making updates impossible). However, this > doesn't seem like a case where we could get somebody stuck very easily, and > I don't see a practical way of making the decision on the server if it > requires this much information. > > On 2016-05-12 01:07 PM, Ted Mielczarek wrote: > >> I suspect we'd want to add some extra token like "it's ok to update this >> 32-bit build to a 64-bit build", and have all the gating logic live on >> the client-side. Odds are if we want to change the criteria we'd have to >> change the client anyway. >> >> -Ted >> >> On Thu, May 12, 2016, at 12:56 PM, Ben Hearsum wrote: >> >>> Do you have thoughts on how we'll be able to serve the users the correct >>> build if we have to base the decision on plugins they may have or other >>> information that's not in the update ping? We can already detect 32-bit >>> builds on 64-bit Windows through the build target, but information about >>> plugins or RAM is not something we know about when serving updates. >>> >>> On 2016-05-12 11:45 AM, Ted Mielczarek wrote: >>> Hello, Given all the discussion around SSE[2] lately, I was curious as to whether we had made any plans to update Windows users that are running 32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows builds. The 64-bit Windows builds do use SSE2, since that's a baseline requirement for x86-64 processors, and the overall performance should generally be better (modulo memory usage, I'm not sure if we have an exact comparison). Additionally 64-bit builds are much less likely to encounter OOM crashes due to address space fragmentation since they have a very large address space compared to the maximum 4GB available to the 32-bit builds. It does seem like we'd need some minimal checking here, obviously first for whether the user is running 64-bit Windows, but also possibly whether they use 32-bit plugins (until such time as we unsupport NPAPI). 32-bit plugins will not work on a 64-bit Windows Firefox (we do not have the equivalent of Universal binaries like we do on OS X). -Ted >>> ___ >>> dev-platform mailing list >>> dev-platform@lists.mozilla.org >>> https://lists.mozilla.org/listinfo/dev-platform >>> >> > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
This is a slight change from the current model where we purposely make the client very dumb, and make the decision on the server (to minimize the possibility of client-side bug making updates impossible). However, this doesn't seem like a case where we could get somebody stuck very easily, and I don't see a practical way of making the decision on the server if it requires this much information. On 2016-05-12 01:07 PM, Ted Mielczarek wrote: I suspect we'd want to add some extra token like "it's ok to update this 32-bit build to a 64-bit build", and have all the gating logic live on the client-side. Odds are if we want to change the criteria we'd have to change the client anyway. -Ted On Thu, May 12, 2016, at 12:56 PM, Ben Hearsum wrote: Do you have thoughts on how we'll be able to serve the users the correct build if we have to base the decision on plugins they may have or other information that's not in the update ping? We can already detect 32-bit builds on 64-bit Windows through the build target, but information about plugins or RAM is not something we know about when serving updates. On 2016-05-12 11:45 AM, Ted Mielczarek wrote: Hello, Given all the discussion around SSE[2] lately, I was curious as to whether we had made any plans to update Windows users that are running 32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows builds. The 64-bit Windows builds do use SSE2, since that's a baseline requirement for x86-64 processors, and the overall performance should generally be better (modulo memory usage, I'm not sure if we have an exact comparison). Additionally 64-bit builds are much less likely to encounter OOM crashes due to address space fragmentation since they have a very large address space compared to the maximum 4GB available to the 32-bit builds. It does seem like we'd need some minimal checking here, obviously first for whether the user is running 64-bit Windows, but also possibly whether they use 32-bit plugins (until such time as we unsupport NPAPI). 32-bit plugins will not work on a 64-bit Windows Firefox (we do not have the equivalent of Universal binaries like we do on OS X). -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
I suspect we'd want to add some extra token like "it's ok to update this 32-bit build to a 64-bit build", and have all the gating logic live on the client-side. Odds are if we want to change the criteria we'd have to change the client anyway. -Ted On Thu, May 12, 2016, at 12:56 PM, Ben Hearsum wrote: > Do you have thoughts on how we'll be able to serve the users the correct > build if we have to base the decision on plugins they may have or other > information that's not in the update ping? We can already detect 32-bit > builds on 64-bit Windows through the build target, but information about > plugins or RAM is not something we know about when serving updates. > > On 2016-05-12 11:45 AM, Ted Mielczarek wrote: > > Hello, > > > > Given all the discussion around SSE[2] lately, I was curious as to > > whether we had made any plans to update Windows users that are running > > 32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows > > builds. The 64-bit Windows builds do use SSE2, since that's a baseline > > requirement for x86-64 processors, and the overall performance should > > generally be better (modulo memory usage, I'm not sure if we have an > > exact comparison). Additionally 64-bit builds are much less likely to > > encounter OOM crashes due to address space fragmentation since they have > > a very large address space compared to the maximum 4GB available to the > > 32-bit builds. > > > > It does seem like we'd need some minimal checking here, obviously first > > for whether the user is running 64-bit Windows, but also possibly > > whether they use 32-bit plugins (until such time as we unsupport NPAPI). > > 32-bit plugins will not work on a 64-bit Windows Firefox (we do not have > > the equivalent of Universal binaries like we do on OS X). > > > > -Ted > > > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
Do you have thoughts on how we'll be able to serve the users the correct build if we have to base the decision on plugins they may have or other information that's not in the update ping? We can already detect 32-bit builds on 64-bit Windows through the build target, but information about plugins or RAM is not something we know about when serving updates. On 2016-05-12 11:45 AM, Ted Mielczarek wrote: Hello, Given all the discussion around SSE[2] lately, I was curious as to whether we had made any plans to update Windows users that are running 32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows builds. The 64-bit Windows builds do use SSE2, since that's a baseline requirement for x86-64 processors, and the overall performance should generally be better (modulo memory usage, I'm not sure if we have an exact comparison). Additionally 64-bit builds are much less likely to encounter OOM crashes due to address space fragmentation since they have a very large address space compared to the maximum 4GB available to the 32-bit builds. It does seem like we'd need some minimal checking here, obviously first for whether the user is running 64-bit Windows, but also possibly whether they use 32-bit plugins (until such time as we unsupport NPAPI). 32-bit plugins will not work on a 64-bit Windows Firefox (we do not have the equivalent of Universal binaries like we do on OS X). -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
On Thursday 2016-05-12 11:45 -0400, Ted Mielczarek wrote: > requirement for x86-64 processors, and the overall performance should > generally be better (modulo memory usage, I'm not sure if we have an > exact comparison). Additionally 64-bit builds are much less likely to > encounter OOM crashes due to address space fragmentation since they have > a very large address space compared to the maximum 4GB available to the > 32-bit builds. Might it be worth considering automatically updating users on machines with 6GB (roughly) or more of RAM, but leaving alone users with less RAM? -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
The DLL Interceptor has some problems on 64-bit Windows 10 that we'd probably want to fix before doing this. See bug 1240977. On 5/12/2016 9:45 AM, Ted Mielczarek wrote: Hello, Given all the discussion around SSE[2] lately, I was curious as to whether we had made any plans to update Windows users that are running 32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows builds. The 64-bit Windows builds do use SSE2, since that's a baseline requirement for x86-64 processors, and the overall performance should generally be better (modulo memory usage, I'm not sure if we have an exact comparison). Additionally 64-bit builds are much less likely to encounter OOM crashes due to address space fragmentation since they have a very large address space compared to the maximum 4GB available to the 32-bit builds. It does seem like we'd need some minimal checking here, obviously first for whether the user is running 64-bit Windows, but also possibly whether they use 32-bit plugins (until such time as we unsupport NPAPI). 32-bit plugins will not work on a 64-bit Windows Firefox (we do not have the equivalent of Universal binaries like we do on OS X). -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Updating 32-bit Windows users to 64-bit Windows builds?
We would have to since other users on the system can have shortcuts pointing to the original location. We've also performed some minimal testing that this is fine when we looked into this a couple of years ago. Robert On Thu, May 12, 2016 at 8:53 AM, Ryan VanderMeulenwrote: > How would we handle going from Program Files (x86) to Program Files? Just > leave the install directory as-is for updates? > > > On 5/12/2016 11:45 AM, Ted Mielczarek wrote: > >> Hello, >> >> Given all the discussion around SSE[2] lately, I was curious as to >> whether we had made any plans to update Windows users that are running >> 32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows >> builds. The 64-bit Windows builds do use SSE2, since that's a baseline >> requirement for x86-64 processors, and the overall performance should >> generally be better (modulo memory usage, I'm not sure if we have an >> exact comparison). Additionally 64-bit builds are much less likely to >> encounter OOM crashes due to address space fragmentation since they have >> a very large address space compared to the maximum 4GB available to the >> 32-bit builds. >> >> It does seem like we'd need some minimal checking here, obviously first >> for whether the user is running 64-bit Windows, but also possibly >> whether they use 32-bit plugins (until such time as we unsupport NPAPI). >> 32-bit plugins will not work on a 64-bit Windows Firefox (we do not have >> the equivalent of Universal binaries like we do on OS X). >> >> -Ted >> >> > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Updating 32-bit Windows users to 64-bit Windows builds?
Hello, Given all the discussion around SSE[2] lately, I was curious as to whether we had made any plans to update Windows users that are running 32-bit Windows builds on a 64-bit Windows OS to our 64-bit Windows builds. The 64-bit Windows builds do use SSE2, since that's a baseline requirement for x86-64 processors, and the overall performance should generally be better (modulo memory usage, I'm not sure if we have an exact comparison). Additionally 64-bit builds are much less likely to encounter OOM crashes due to address space fragmentation since they have a very large address space compared to the maximum 4GB available to the 32-bit builds. It does seem like we'd need some minimal checking here, obviously first for whether the user is running 64-bit Windows, but also possibly whether they use 32-bit plugins (until such time as we unsupport NPAPI). 32-bit plugins will not work on a 64-bit Windows Firefox (we do not have the equivalent of Universal binaries like we do on OS X). -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform