Re: Updating 32-bit Windows users to 64-bit Windows builds?

[Eric Rahm]

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?

[Tobias B. Besemer]

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?

[Robert Strong]

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?

[Tobias B. Besemer]

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 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?

[Tobias B. Besemer]

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?

[Tobias B. Besemer]

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?

[Tobias B. Besemer]

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?

[Tobias B. Besemer]

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?

[L. David Baron]

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?

[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

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

Re: Updating 32-bit Windows users to 64-bit Windows builds?

[Andrew McCreight]

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?

[keithgallistel]

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?

[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.

___
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?

[keithgallistel]

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?

[bowen]

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?

[khagaroth]

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?

[L. David Baron]

On Thursday 2016-05-12 15:33 -0700, Kyle Huey wrote:
> On Thu, May 12, 2016 at 2:46 PM, 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.
> >
> 
> 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?

[Kyle Huey]

On Thu, May 12, 2016 at 2:46 PM, 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.
>

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?

[Eric Rahm]

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 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.
> ___
> 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?

[Karl Tomlinson]

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?

[Chris Peterson]

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 Hearsum 
wrote:


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?

[Ryan VanderMeulen]

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 Hearsum  wrote:


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?

[Lawrence Mandel]

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 Hearsum  wrote:

> 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?

[Ben Hearsum]

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?

[Ted Mielczarek]

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?

[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.


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?

[L. 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?

-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?

[Aaron Klotz]

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?

[Robert Strong]

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 VanderMeulen  wrote:

> 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?

[Ted Mielczarek]

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