Re: 64-bit Firefox progress report: 2017-07-18

[Chris Peterson]

I see what you mean. The chart is abstract, but I see how the relative 
sizes do imply more than intended. I like your suggestion to use up and 
down arrows.


chris


On 2017-08-14 7:42 PM, Ben Kelly wrote:

Chris,

Do you know who controls this blog post?

https://blog.mozilla.org/firefox/firefox-64-default-64-bit-windows/

The chart is really misleading.  What does the vertical bar chart for
"security" even mean?  As noted on twitter:

https://twitter.com/kylealden/status/897222041476005888

The bar chart for "crashes" at least has an intelligible y-axis, but it
seems wrong.  The chart shows more like a 60% improvement instead of a 39%
improvement.

Perhaps we should just replace this graphic with an up-arrow for security
and a down-arrow for crashes?

Anyway, sorry to be pedantic, but misleading charts are kind of a pet peeve.

Thanks.

Ben

On Wed, Jul 19, 2017 at 2:38 AM, Chris Peterson 
wrote:


We are on track to make 64-bit Firefox the default build for Win64 OS,
bringing improved ASLR and fewer OOM crashes to the 70% of Windows Firefox
users running Win64.

PLANS:

* In Firefox 55 (August 8), the Windows stub installer will default to
64-bit Firefox for eligible users (Win64 and 2+ GB RAM).

* In Firefox 56 (September 26), we will migrate existing eligible 32-bit
Firefox users to 64-bit. About 70% of Windows Firefox users currently run
32-bit Firefox build on Win64. Nearly all of these users can be migrated to
64-bit Firefox.

Our Win64 project wiki has more details about the long road to making
64-bit Firefox the default:

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

PROGRESS:

* David Parks fixed the insidious Flash video streaming bug affecting
Xfinity and MLB! (bug 1334803)

* Bob Owen fixed the sandbox issue that prevented 64-bit Firefox from
being run from a network-mounted drive! (bug 1377555)

* Some highlights from week 2 of our Firefox 54 experiment comparing 32-
and 64-bit Firefox users:

- About 8% of Windows users have <= 2 GB RAM!

- User retention and engagement metrics (session length, # of pages, # of
tabs) are about the same for 32- and 64-bit Firefox users, regardless of
memory size.

- 64-bit content process crash rate is about the same as 32-bit for users
with 2 GB and about 20% less with 2+ GB!

- 64-bit browser process crash rate is about the same as 32-bit for users
with 2 GB and about 20% less with 2+ GB!

- 64-bit plugin process crash rate is about 50% less than 32-bit for users
with 2 GB and 80% less with 2+ GB!

We are still considering whether 64-bit Firefox should have a default
minimum memory requirement. As a placeholder value, Firefox 55 currently
requires 2+ GB, but based on the results of our experiment, we may remove
the minimum memory requirement. Microsoft's minimum memory require for
Win64 itself is 2 GB, so anyone running Win64 with less than 2 GB is having
a bad time.
___
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: 64-bit Firefox progress report: 2017-07-18

[Ben Kelly]

Chris,

Do you know who controls this blog post?

https://blog.mozilla.org/firefox/firefox-64-default-64-bit-windows/

The chart is really misleading.  What does the vertical bar chart for
"security" even mean?  As noted on twitter:

https://twitter.com/kylealden/status/897222041476005888

The bar chart for "crashes" at least has an intelligible y-axis, but it
seems wrong.  The chart shows more like a 60% improvement instead of a 39%
improvement.

Perhaps we should just replace this graphic with an up-arrow for security
and a down-arrow for crashes?

Anyway, sorry to be pedantic, but misleading charts are kind of a pet peeve.

Thanks.

Ben

On Wed, Jul 19, 2017 at 2:38 AM, Chris Peterson 
wrote:

> We are on track to make 64-bit Firefox the default build for Win64 OS,
> bringing improved ASLR and fewer OOM crashes to the 70% of Windows Firefox
> users running Win64.
>
> PLANS:
>
> * In Firefox 55 (August 8), the Windows stub installer will default to
> 64-bit Firefox for eligible users (Win64 and 2+ GB RAM).
>
> * In Firefox 56 (September 26), we will migrate existing eligible 32-bit
> Firefox users to 64-bit. About 70% of Windows Firefox users currently run
> 32-bit Firefox build on Win64. Nearly all of these users can be migrated to
> 64-bit Firefox.
>
> Our Win64 project wiki has more details about the long road to making
> 64-bit Firefox the default:
>
> https://wiki.mozilla.org/Firefox/Win64
>
> PROGRESS:
>
> * David Parks fixed the insidious Flash video streaming bug affecting
> Xfinity and MLB! (bug 1334803)
>
> * Bob Owen fixed the sandbox issue that prevented 64-bit Firefox from
> being run from a network-mounted drive! (bug 1377555)
>
> * Some highlights from week 2 of our Firefox 54 experiment comparing 32-
> and 64-bit Firefox users:
>
> - About 8% of Windows users have <= 2 GB RAM!
>
> - User retention and engagement metrics (session length, # of pages, # of
> tabs) are about the same for 32- and 64-bit Firefox users, regardless of
> memory size.
>
> - 64-bit content process crash rate is about the same as 32-bit for users
> with 2 GB and about 20% less with 2+ GB!
>
> - 64-bit browser process crash rate is about the same as 32-bit for users
> with 2 GB and about 20% less with 2+ GB!
>
> - 64-bit plugin process crash rate is about 50% less than 32-bit for users
> with 2 GB and 80% less with 2+ GB!
>
> We are still considering whether 64-bit Firefox should have a default
> minimum memory requirement. As a placeholder value, Firefox 55 currently
> requires 2+ GB, but based on the results of our experiment, we may remove
> the minimum memory requirement. Microsoft's minimum memory require for
> Win64 itself is 2 GB, so anyone running Win64 with less than 2 GB is having
> a bad time.
> ___
> 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: 64-bit Firefox progress report: 2017-07-18

[Chris Peterson]

On 2017-08-07 1:19 AM, Nicholas Nethercote wrote:

I think the 2GB "requirement" from Microsoft should be ignored, because
plenty of our users are ignoring it.


By "ignore the 2GB requirement", are you suggesting we do or don't give 
64-bit Firefox to users with less than 2GB?


I am waffling again on having a minimum memory requirement at all. Our 
current minimum is actually 1800 MB, not 2048 MB. Only about 1% of Win64 
OS users actually have (0,1800) MB and only 5% have [1800,2048] MB. So 
we are talking about small differences in user retention and crash rates 
for only 1% of Win64 OS users.


As we are preparing to migrate Beta users to 64-bit, we see the minimum 
memory requirement adds new complexity to both the client and server 
components of the update process and extra QA for this one-time 
migration event.




On Mon, Aug 7, 2017 at 5:51 PM, Chris Peterson 
wrote:


On 2017-08-06 11:26 PM, Henri Sivonen wrote:


On Thu, Jul 20, 2017 at 10:42 AM, Chris Peterson
wrote:


Users with only 2 GB and 5 minute browser sessions would probably have a
faster user experience with 32-bit Firefox than with 64-bit, but how do
we
weigh that experience versus the security benefits of ASLR?


Not giving users a security mechanism due to a non-obvious reason
feels bad. Furthermore, considering that Microsoft documents 2 GB as a
"requirement" for 64-bit Windows, is it really worthwhile for us to
treat three Windows pointer size combinations (32-bit on 32-bit,
64-bit on 64-bit and 32-bit on 64-bit) as fully supported when one of
the combinations is in contradiction with the OS vendor's stated
requirements?

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



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

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

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

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

___
dev-platform mailing list
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: 64-bit Firefox progress report: 2017-07-18

[Chris Peterson]

Correction to my earlier claims about our minimum memory requirement.

The stub installer will default to 64-bit for users with >= 1800 MB. So 
users with exactly 2 GB should get 64-bit Firefox. Only Win64 users with 
strictly less than 2 GB will default to 32-bit Firefox.


Why the magic number 1800 MB? The Windows API we use to query the 
machine's available memory omits physical memory reserved for hardware 
drivers, which is typically a couple hundred KB. So most "2 GB" machines 
will report less than 2048 MB available memory.


Stub installer's memory check:
https://searchfox.org/mozilla-central/source/browser/installer/windows/nsis/stub.nsi#189-195


On 2017-08-07 1:19 AM, Nicholas Nethercote wrote:
I think the 2GB "requirement" from Microsoft should be ignored, 
because plenty of our users are ignoring it.


Nick

On Mon, Aug 7, 2017 at 5:51 PM, Chris Peterson > wrote:


On 2017-08-06 11:26 PM, Henri Sivonen wrote:

On Thu, Jul 20, 2017 at 10:42 AM, Chris
Petersonmailto:cpeter...@mozilla.com>>
wrote:

Users with only 2 GB and 5 minute browser sessions would
probably have a
faster user experience with 32-bit Firefox than with
64-bit, but how do we
weigh that experience versus the security benefits of ASLR?

Not giving users a security mechanism due to a non-obvious reason
feels bad. Furthermore, considering that Microsoft documents 2
GB as a
"requirement" for 64-bit Windows, is it really worthwhile for
us to
treat three Windows pointer size combinations (32-bit on 32-bit,
64-bit on 64-bit and 32-bit on 64-bit) as fully supported when
one of
the combinations is in contradiction with the OS vendor's stated
requirements?

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


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

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

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

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

___
dev-platform mailing list
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: 64-bit Firefox progress report: 2017-07-18

[Ryan VanderMeulen]

On 8/7/2017 3:51 AM, Chris Peterson wrote:

Do we test 32-bit Firefox on Win32 or Win64 today?


Our Win32 tests run on 32-bit Windows 7 instances. I don't know offhand 
if we're using the /3GB switch or not.


-Ryan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 64-bit Firefox progress report: 2017-07-18

[Nicholas Nethercote]

I think the 2GB "requirement" from Microsoft should be ignored, because
plenty of our users are ignoring it.

Nick

On Mon, Aug 7, 2017 at 5:51 PM, Chris Peterson 
wrote:

> On 2017-08-06 11:26 PM, Henri Sivonen wrote:
>
>> On Thu, Jul 20, 2017 at 10:42 AM, Chris Peterson
>> wrote:
>>
>>> Users with only 2 GB and 5 minute browser sessions would probably have a
>>> faster user experience with 32-bit Firefox than with 64-bit, but how do
>>> we
>>> weigh that experience versus the security benefits of ASLR?
>>>
>> Not giving users a security mechanism due to a non-obvious reason
>> feels bad. Furthermore, considering that Microsoft documents 2 GB as a
>> "requirement" for 64-bit Windows, is it really worthwhile for us to
>> treat three Windows pointer size combinations (32-bit on 32-bit,
>> 64-bit on 64-bit and 32-bit on 64-bit) as fully supported when one of
>> the combinations is in contradiction with the OS vendor's stated
>> requirements?
>>
>> Do we have any metrics on whether 32-bit on 64-bit exhibits bugs that
>> 32-bit on 32-bit and 64-bit on 64-bit don't? That is, what kind of bug
>> burden are we keeping by catering to users who've installed 64-bit
>> Windows with less than 2 GB of RAM in contradiction with what
>> Microsoft states as a requirement?
>>
>
> That's a fair question. 32-bit applications can only access 2 GB of
> virtual address space on Win32 OS, but can access 4 GB on Win64 OS. So in
> theory, some 32-bit pointer bugs could manifest differently on Win64 and
> Win32.
>
> Do we test 32-bit Firefox on Win32 or Win64 today? I know we build 32-bit
> Firefox on Win64. Since more people will run 32-bit Firefox on Win32 than
> on Win64, we should probably test on Win32 or at least test on Win64
> configured to only allow Firefox access to 2 GB of virtual address space.
>
> In our experiments with Win64 OS users, users with 2 GB or less had
> slightly worse retention and crash rates when running 64-bit Firefox than
> 32-bit Firefox.
>
> About 8% of Win64 users in our experiment had 2 GB or less, so we are
> talking about choosing a worse user experience for a fair number of people.
> (We didn't break out how many users had strictly less than 2 GB.) 64-bit
> Chrome's minimum memory requirement is 4 GB, so Google has similarly
> decided that supporting 32-bit on Win64 is worth the trouble.
>
> ___
> dev-platform mailing list
> 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: 64-bit Firefox progress report: 2017-07-18

[Chris Peterson]

On 2017-08-06 11:26 PM, Henri Sivonen wrote:

On Thu, Jul 20, 2017 at 10:42 AM, Chris Peterson  wrote:

Users with only 2 GB and 5 minute browser sessions would probably have a
faster user experience with 32-bit Firefox than with 64-bit, but how do we
weigh that experience versus the security benefits of ASLR?

Not giving users a security mechanism due to a non-obvious reason
feels bad. Furthermore, considering that Microsoft documents 2 GB as a
"requirement" for 64-bit Windows, is it really worthwhile for us to
treat three Windows pointer size combinations (32-bit on 32-bit,
64-bit on 64-bit and 32-bit on 64-bit) as fully supported when one of
the combinations is in contradiction with the OS vendor's stated
requirements?

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


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


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


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


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

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 64-bit Firefox progress report: 2017-07-18

[Henri Sivonen]

On Thu, Jul 20, 2017 at 10:42 AM, Chris Peterson  wrote:
> Users with only 2 GB and 5 minute browser sessions would probably have a
> faster user experience with 32-bit Firefox than with 64-bit, but how do we
> weigh that experience versus the security benefits of ASLR?

Not giving users a security mechanism due to a non-obvious reason
feels bad. Furthermore, considering that Microsoft documents 2 GB as a
"requirement" for 64-bit Windows, is it really worthwhile for us to
treat three Windows pointer size combinations (32-bit on 32-bit,
64-bit on 64-bit and 32-bit on 64-bit) as fully supported when one of
the combinations is in contradiction with the OS vendor's stated
requirements?

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

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 64-bit Firefox progress report: 2017-07-18

[Jean-Yves Avenard]

Hi

On Wed, Jul 19, 2017 at 9:01 AM, Mike Hommey  wrote:
> What's the plan for eligible people that still want to keep 32-bit
> Firefox? Are they going to have to stop auto upgrades, which would get
> them automatically on 64-bits and upgrade manually? This is especially
> going to be a problem for users with less than 2GB RAM that do still
> want 32-bit Firefox if we decide against the minimum memory requirement.

Just curious.

What would be the rationale behind this choice?

JY
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 64-bit Firefox progress report: 2017-07-18

[Chris Peterson]

On 2017-07-19 6:58 PM, Mike Hommey wrote:

I don't understand why that would be, but if so it should show in
crashstats as fewer small OOMs on these devices.  Does the data actually
show that?


I don't know. Can that be filtered?


I'm not sure I'm answering the right question, but searching through 
crash reports from Firefox 53/54 users over the last 30 days, I see 
small OOMs from both 32- and 64-bit users, regardless of available 
physical or virtual memory or browser uptime. But small OOMs are always 
the top crash (10% or more) for 32-bit users. Small OOMs are about 6% 
for 64-bit users with <= 2 GB, 3% with <= 4 GB, and 1% for > 4 GB.


Here is a search for 32-bit crash reports with <= 2 GB physical memory:
https://is.gd/205aNb

And 64-bit crash reports with <= 2 GB physical memory:
https://is.gd/AezNaZ

But I see a lot of strange crash reports, such as small OOMs from 64-bit 
users within 10 seconds of starting Firefox. Or small OOMs from 64-bit 
users with 9 GB of available physical memory and 128 TB of available 
virtual memory.




I'm not saying they shut down because of memory. I'm saying a surprising
lot of people have browser sessions that don't last more than 5 minutes
(I've heard multiple times in the past years that we found that out from
our data).
Those people are not going to see OOM.


Users with only 2 GB and 5 minute browser sessions would probably have a 
faster user experience with 32-bit Firefox than with 64-bit, but how do 
we weigh that experience versus the security benefits of ASLR?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 64-bit Firefox progress report: 2017-07-18

[Mike Hommey]

On Wed, Jul 19, 2017 at 09:40:12PM -0400, Ben Kelly wrote:
> On Jul 19, 2017 8:57 PM, "Mike Hommey"  wrote:
> 
> On Wed, Jul 19, 2017 at 08:48:45PM -0400, Ben Kelly wrote:
> > On Jul 19, 2017 6:20 PM, "Mike Hommey"  wrote:
> >
> > > What would be the rationale behind this choice?
> >
> > Smaller memory footprint, which, you'll admit, when you're on a machine
> > with (less than) 2GB RAM, makes a difference.
> >
> >
> > I thought we had data that showed OOM (small) due to VM fragmentation
> still
> > outweighed OOM (large) on these machines.  If that is the case 64-bit is
> > strictly better.
> 
> I don't believe you can exhaust the address space and have VM
> fragmentation be an actual problem when you have less than 2GB RAM. Of
> if you do, everything is slow to a crawl before that happens.
> 
> 
> I don't understand why that would be, but if so it should show in
> crashstats as fewer small OOMs on these devices.  Does the data actually
> show that?

I don't know. Can that be filtered?

> Also, that tells nothing about people that never hit OOM (a lot of
> people even close their browser well before that could happen).
> 
> 
> You're saying the size difference between 32-bit and 64-bit is so great
> users will start manually shutting down?  I find that hard to believe.  If
> they are shutting down apps to save memory they will probably do it with
> both 32-bit and 64-bit.  Again, though, in theory we have usage hour
> telemetry we could look at to confirm (although maybe only for beta?).

I'm not saying they shut down because of memory. I'm saying a surprising
lot of people have browser sessions that don't last more than 5 minutes
(I've heard multiple times in the past years that we found that out from
our data).
Those people are not going to see OOM.

Mike

PS: your mailer likes to not put quotation marks, making your messages
hard to follow. I thought that was because it's sending both a text and
an html version, and the text version sucks, but it appears it's not
sending an html version...
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 64-bit Firefox progress report: 2017-07-18

[Ben Kelly]

On Jul 19, 2017 8:57 PM, "Mike Hommey"  wrote:

On Wed, Jul 19, 2017 at 08:48:45PM -0400, Ben Kelly wrote:
> On Jul 19, 2017 6:20 PM, "Mike Hommey"  wrote:
>
> > What would be the rationale behind this choice?
>
> Smaller memory footprint, which, you'll admit, when you're on a machine
> with (less than) 2GB RAM, makes a difference.
>
>
> I thought we had data that showed OOM (small) due to VM fragmentation
still
> outweighed OOM (large) on these machines.  If that is the case 64-bit is
> strictly better.

I don't believe you can exhaust the address space and have VM
fragmentation be an actual problem when you have less than 2GB RAM. Of
if you do, everything is slow to a crawl before that happens.


I don't understand why that would be, but if so it should show in
crashstats as fewer small OOMs on these devices.  Does the data actually
show that?

Also, that tells nothing about people that never hit OOM (a lot of
people even close their browser well before that could happen).


You're saying the size difference between 32-bit and 64-bit is so great
users will start manually shutting down?  I find that hard to believe.  If
they are shutting down apps to save memory they will probably do it with
both 32-bit and 64-bit.  Again, though, in theory we have usage hour
telemetry we could look at to confirm (although maybe only for beta?).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 64-bit Firefox progress report: 2017-07-18

[Mike Hommey]

On Wed, Jul 19, 2017 at 08:48:45PM -0400, Ben Kelly wrote:
> On Jul 19, 2017 6:20 PM, "Mike Hommey"  wrote:
> 
> > What would be the rationale behind this choice?
> 
> Smaller memory footprint, which, you'll admit, when you're on a machine
> with (less than) 2GB RAM, makes a difference.
> 
> 
> I thought we had data that showed OOM (small) due to VM fragmentation still
> outweighed OOM (large) on these machines.  If that is the case 64-bit is
> strictly better.

I don't believe you can exhaust the address space and have VM
fragmentation be an actual problem when you have less than 2GB RAM. Of
if you do, everything is slow to a crawl before that happens.

Also, that tells nothing about people that never hit OOM (a lot of
people even close their browser well before that could happen).

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 64-bit Firefox progress report: 2017-07-18

[Ben Kelly]

On Jul 19, 2017 6:20 PM, "Mike Hommey"  wrote:

> What would be the rationale behind this choice?

Smaller memory footprint, which, you'll admit, when you're on a machine
with (less than) 2GB RAM, makes a difference.


I thought we had data that showed OOM (small) due to VM fragmentation still
outweighed OOM (large) on these machines.  If that is the case 64-bit is
strictly better.

Ben
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 64-bit Firefox progress report: 2017-07-18

[Mike Hommey]

On Thu, Jul 20, 2017 at 12:01:04AM +0200, Jean-Yves Avenard wrote:
> Hi
> 
> On Wed, Jul 19, 2017 at 9:01 AM, Mike Hommey  wrote:
> > What's the plan for eligible people that still want to keep 32-bit
> > Firefox? Are they going to have to stop auto upgrades, which would get
> > them automatically on 64-bits and upgrade manually? This is especially
> > going to be a problem for users with less than 2GB RAM that do still
> > want 32-bit Firefox if we decide against the minimum memory requirement.
> 
> Just curious.
> 
> What would be the rationale behind this choice?

Smaller memory footprint, which, you'll admit, when you're on a machine
with (less than) 2GB RAM, makes a difference.

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 64-bit Firefox progress report: 2017-07-18

[Chris Peterson]

On 2017-07-19 10:18 AM, Mike Hoye wrote:

On 2017-07-19 3:58 AM, Chris Peterson wrote:

On 2017-07-19 12:01 AM, Mike Hommey wrote:

What's the plan for eligible people that still want to keep 32-bit
Firefox? 
Outside of our QA team (or others orgs, I guess?) do we have a set of 
use cases that would motivate people to flip that switch?


64-bit code is slightly larger, so there is some memory overheard. Users 
with less than 4 GB RAM might feel that 32-bit is faster on their 
machine, but our testing on Windows 7 and 10 machines with just 2 GB RAM 
doesn't show any measurable performance differences. We don't expect 
64-bit Firefox to have any performance improvements over 32-bit. The 
benefits of 64-bit are primarily ASLR and fewer OOM crashes, which are 
somewhat intangible to end users.




Are they going to have to stop auto upgrades, which would get
them automatically on 64-bits and upgrade manually? This is especially
going to be a problem for users with less than 2GB RAM that do still
want 32-bit Firefox if we decide against the minimum memory 
requirement.


We have two options in mind: 
Is ESR on the radar while you're planning this, or is it unrelated? 


When the next ESR comes around (59?), we will announce to the ESR 
mailing list that 64-bit is considered stable and the preferred version, 
but we do not plan to auto migrate 32-bit ESR users to 64-bit. We figure 
that enterprises will want to test and control their deployments.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 64-bit Firefox progress report: 2017-07-18

[Mike Hoye]

On 2017-07-19 3:58 AM, Chris Peterson wrote:


On 2017-07-19 12:01 AM, Mike Hommey wrote:

What's the plan for eligible people that still want to keep 32-bit
Firefox? 
Outside of our QA team (or others orgs, I guess?) do we have a set of 
use cases that would motivate people to flip that switch?




Are they going to have to stop auto upgrades, which would get
them automatically on 64-bits and upgrade manually? This is especially
going to be a problem for users with less than 2GB RAM that do still
want 32-bit Firefox if we decide against the minimum memory requirement.


We have two options in mind: 

Is ESR on the radar while you're planning this, or is it unrelated?

- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 64-bit Firefox progress report: 2017-07-18

[Chris Peterson]

On 2017-07-19 12:01 AM, Mike Hommey wrote:

What's the plan for eligible people that still want to keep 32-bit
Firefox? Are they going to have to stop auto upgrades, which would get
them automatically on 64-bits and upgrade manually? This is especially
going to be a problem for users with less than 2GB RAM that do still
want 32-bit Firefox if we decide against the minimum memory requirement.


We have two options in mind:

1. An opt-out registry key (piggybacking on an updater feature mhowell 
or rstrong is developing). We would document this registry key before 
the 56 release so 32-bit users would have time to set it and prevent 
migration.


2. 56 will be a watershed release (for multiple reasons), so all users 
updating from old versions will get 56.0 before then updating to any 
future updates. We will limit the migration to exactly one version 
(probably a 56.0.1) so 32-bit users who were migrated but don't want 
64-bit can manually re-install 32-bit 56.0.1 and not be re-migrated in a 
later update.




Other than end users, I can imagine it being a problem for developers or
QA at some point.

Also, what about beta, developer edition and nightly?


Our current plan is to not migrate 32-bit Nightly users to 64-bit. We 
haven't made a decision about Beta or Developer Edition users. About 60% 
of Beta users don't actually know they are on the Beta channel, so they 
are not typical pre-release testers and would benefit from 64-bit. With 
the opt-out registry key and the 56.0.1 watershed migration, there are 
options for developers and testers who don't want to be migrated. Given 
the options, is there any strong reason to not migrate Beta and/or 
Developer Edition users?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: 64-bit Firefox progress report: 2017-07-18

[Mike Hommey]

On Tue, Jul 18, 2017 at 11:38:56PM -0700, Chris Peterson wrote:
> We are on track to make 64-bit Firefox the default build for Win64 OS,
> bringing improved ASLR and fewer OOM crashes to the 70% of Windows Firefox
> users running Win64.
> 
> PLANS:
> 
> * In Firefox 55 (August 8), the Windows stub installer will default to
> 64-bit Firefox for eligible users (Win64 and 2+ GB RAM).
> 
> * In Firefox 56 (September 26), we will migrate existing eligible 32-bit
> Firefox users to 64-bit. About 70% of Windows Firefox users currently run
> 32-bit Firefox build on Win64. Nearly all of these users can be migrated to
> 64-bit Firefox.

What's the plan for eligible people that still want to keep 32-bit
Firefox? Are they going to have to stop auto upgrades, which would get
them automatically on 64-bits and upgrade manually? This is especially
going to be a problem for users with less than 2GB RAM that do still
want 32-bit Firefox if we decide against the minimum memory requirement.
Other than end users, I can imagine it being a problem for developers or
QA at some point.

Also, what about beta, developer edition and nightly?

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

64-bit Firefox progress report: 2017-07-18

[Chris Peterson]

We are on track to make 64-bit Firefox the default build for Win64 OS, 
bringing improved ASLR and fewer OOM crashes to the 70% of Windows 
Firefox users running Win64.


PLANS:

* In Firefox 55 (August 8), the Windows stub installer will default to 
64-bit Firefox for eligible users (Win64 and 2+ GB RAM).


* In Firefox 56 (September 26), we will migrate existing eligible 32-bit 
Firefox users to 64-bit. About 70% of Windows Firefox users currently 
run 32-bit Firefox build on Win64. Nearly all of these users can be 
migrated to 64-bit Firefox.


Our Win64 project wiki has more details about the long road to making 
64-bit Firefox the default:


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

PROGRESS:

* David Parks fixed the insidious Flash video streaming bug affecting 
Xfinity and MLB! (bug 1334803)


* Bob Owen fixed the sandbox issue that prevented 64-bit Firefox from 
being run from a network-mounted drive! (bug 1377555)


* Some highlights from week 2 of our Firefox 54 experiment comparing 32- 
and 64-bit Firefox users:


- About 8% of Windows users have <= 2 GB RAM!

- User retention and engagement metrics (session length, # of pages, # 
of tabs) are about the same for 32- and 64-bit Firefox users, regardless 
of memory size.


- 64-bit content process crash rate is about the same as 32-bit for 
users with 2 GB and about 20% less with 2+ GB!


- 64-bit browser process crash rate is about the same as 32-bit for 
users with 2 GB and about 20% less with 2+ GB!


- 64-bit plugin process crash rate is about 50% less than 32-bit for 
users with 2 GB and 80% less with 2+ GB!


We are still considering whether 64-bit Firefox should have a default 
minimum memory requirement. As a placeholder value, Firefox 55 currently 
requires 2+ GB, but based on the results of our experiment, we may 
remove the minimum memory requirement. Microsoft's minimum memory 
require for Win64 itself is 2 GB, so anyone running Win64 with less than 
2 GB is having a bad time.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform