info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Google announces Chrome builds for Win64
717 views
Skip to first unread message
Chris Peterson
Jun 3, 2014, 2:37:16 PM6/3/14
to
http://blog.chromium.org/2014/06/try-out-new-64-bit-windows-canary-and.html
What is the status of Firefox builds for Win64? When Mozilla releases
Win64 builds (again), we'll be seen as reacting to Google when we've
actually been working on it for a while. :\
chris
What is the status of Firefox builds for Win64? When Mozilla releases
Win64 builds (again), we'll be seen as reacting to Google when we've
actually been working on it for a while. :\
chris
Ehsan Akhgari
Jun 3, 2014, 3:51:36 PM6/3/14
to Chris Peterson, dev-pl...@lists.mozilla.org, David Major
Cheers,
Ehsan
jmo...@mozilla.com
Jun 4, 2014, 10:32:55 AM6/4/14
to
Hi folks. I should introduce myself first. I'm a new product manager working on Firefox for Desktop. I've been working on an assessment of launching 64 bit for about 6 weeks. In that time, I've had conversations with representatives from every engineering and QA team whose work would be required to launch and support 64 bit, as well as strategy and marketing team members.
We have a good understanding of the work required. The development work, as you might suspect, is largely done. We still produce 64 bit builds. The notable areas remaining are:
- completing test coverage
- working on plugin/add-on compatibility
- writing/updating the installer
- automating/augmenting/reallocating QA resources to support the additional QA needs on an ongoing basis, and
- some open product questions around how we roll it out, how we announce and promote it, etc.
That's just the work, it is known and straightforward, though not trivial. Choosing to advance 64 means putting something else on hold. Therefore, we are also looking at the reasons to launch 64 bit. There are user reasons to do this, and there are Mozilla innovation reasons to do this. We have also been watching industry estimates of 64 bit Windows adoption, because we need to understand how many users would benefit from 64 bit.
The overwhelming majority of Internet users could neither tell you what 64 bit means, nor will they have seen Google's announcement.
Still Chris, you're absolutely correct. Many of the Mozilla faithful and industry watchers may think we're reacting to Google. The bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=1007726. We actually began informal conversations a few weeks before I entered the bug. The Mozilla community and press will hopefully take that into consideration in judging our intent, but it's important for us to get our timing right than to try to win at the PR race.
Remaining on par with other browsers is a big consideration in launching 64 bit, but as I mentioned above, the primary drivers must be because it's better for users, because it allows Mozilla to advance the browser innovations we've already been working on, and above all that the user base is willing and able to take advantage of it.
Above all, I want to reassure you we are being methodical about the timing and planning of 64 bit. We don't have the resources other companies have, and a decision to advance one area means putting another on hold.
Lastly, 64 bit is exciting. I'm glad we're having these conversations, and Ive been thrilled to be able to work on it.
I will update that bug ticket above in the near future, and we'll keep the community notified when things start moving.
Thanks,
Javaun Moradi
We have a good understanding of the work required. The development work, as you might suspect, is largely done. We still produce 64 bit builds. The notable areas remaining are:
- completing test coverage
- working on plugin/add-on compatibility
- writing/updating the installer
- automating/augmenting/reallocating QA resources to support the additional QA needs on an ongoing basis, and
- some open product questions around how we roll it out, how we announce and promote it, etc.
That's just the work, it is known and straightforward, though not trivial. Choosing to advance 64 means putting something else on hold. Therefore, we are also looking at the reasons to launch 64 bit. There are user reasons to do this, and there are Mozilla innovation reasons to do this. We have also been watching industry estimates of 64 bit Windows adoption, because we need to understand how many users would benefit from 64 bit.
The overwhelming majority of Internet users could neither tell you what 64 bit means, nor will they have seen Google's announcement.
Still Chris, you're absolutely correct. Many of the Mozilla faithful and industry watchers may think we're reacting to Google. The bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=1007726. We actually began informal conversations a few weeks before I entered the bug. The Mozilla community and press will hopefully take that into consideration in judging our intent, but it's important for us to get our timing right than to try to win at the PR race.
Remaining on par with other browsers is a big consideration in launching 64 bit, but as I mentioned above, the primary drivers must be because it's better for users, because it allows Mozilla to advance the browser innovations we've already been working on, and above all that the user base is willing and able to take advantage of it.
Above all, I want to reassure you we are being methodical about the timing and planning of 64 bit. We don't have the resources other companies have, and a decision to advance one area means putting another on hold.
Lastly, 64 bit is exciting. I'm glad we're having these conversations, and Ive been thrilled to be able to work on it.
I will update that bug ticket above in the near future, and we'll keep the community notified when things start moving.
Thanks,
Javaun Moradi
Brian Smith
Jun 4, 2014, 1:32:48 PM6/4/14
to Chris Peterson, dev-platform
On Tue, Jun 3, 2014 at 11:37 AM, Chris Peterson <cpet...@mozilla.com>
wrote:
> http://blog.chromium.org/2014/06/try-out-new-64-bit-windows-
mutli-process/sandboxed Firefox? I worry that 64-bit Firefox will be more
memory hungry than 32-bit Firefox and if it lands first then it will be
harder to land multi-process Firefox which is also likely to use more
memory. I think having multi-process sooner is more important than having
64-bit sooner, if there is such a choice to make. IMO, it would be good to
make explicit choices instead of just shipping whichever is done first.
Cheers,
Brian
wrote:
> http://blog.chromium.org/2014/06/try-out-new-64-bit-windows-
> canary-and.html
>
> What is the status of Firefox builds for Win64? When Mozilla releases
> Win64 builds (again), we'll be seen as reacting to Google when we've
> actually been working on it for a while. :\
>
Does it make sense to ship 64-bit Firefox before shipping
>
> What is the status of Firefox builds for Win64? When Mozilla releases
> Win64 builds (again), we'll be seen as reacting to Google when we've
> actually been working on it for a while. :\
>
mutli-process/sandboxed Firefox? I worry that 64-bit Firefox will be more
memory hungry than 32-bit Firefox and if it lands first then it will be
harder to land multi-process Firefox which is also likely to use more
memory. I think having multi-process sooner is more important than having
64-bit sooner, if there is such a choice to make. IMO, it would be good to
make explicit choices instead of just shipping whichever is done first.
Cheers,
Brian
Eric Rescorla
Jun 4, 2014, 1:40:04 PM6/4/14
to Brian Smith, Chris Peterson, dev-platform
On Wed, Jun 4, 2014 at 10:32 AM, Brian Smith <br...@briansmith.org> wrote:
> On Tue, Jun 3, 2014 at 11:37 AM, Chris Peterson <cpet...@mozilla.com>
> wrote:
>
> > http://blog.chromium.org/2014/06/try-out-new-64-bit-windows-
> > canary-and.html
> >
> On Tue, Jun 3, 2014 at 11:37 AM, Chris Peterson <cpet...@mozilla.com>
> wrote:
>
> > http://blog.chromium.org/2014/06/try-out-new-64-bit-windows-
> > canary-and.html
> >
> > What is the status of Firefox builds for Win64? When Mozilla releases
> > Win64 builds (again), we'll be seen as reacting to Google when we've
> > actually been working on it for a while. :\
> >
>
> > Win64 builds (again), we'll be seen as reacting to Google when we've
> > actually been working on it for a while. :\
> >
>
> Does it make sense to ship 64-bit Firefox before shipping
> mutli-process/sandboxed Firefox? I worry that 64-bit Firefox will be more
> memory hungry than 32-bit Firefox and if it lands first then it will be
> harder to land multi-process Firefox which is also likely to use more
> memory. I think having multi-process sooner is more important than having
> 64-bit sooner, if there is such a choice to make. IMO, it would be good to
> make explicit choices instead of just shipping whichever is done first.
>
I suppose it depends on how long it's going to take to land multiprocess
> mutli-process/sandboxed Firefox? I worry that 64-bit Firefox will be more
> memory hungry than 32-bit Firefox and if it lands first then it will be
> harder to land multi-process Firefox which is also likely to use more
> memory. I think having multi-process sooner is more important than having
> 64-bit sooner, if there is such a choice to make. IMO, it would be good to
> make explicit choices instead of just shipping whichever is done first.
>
Firefox. Given that much of the benefit of 64-bit is that ASLR works a lot
better, if we *don't* have multiprocess and aren't going to get it soon,
then it's that much more important to land 64-bit.
-Ekr
jmo...@mozilla.com
Jun 4, 2014, 2:07:11 PM6/4/14
to
Great point Brian, I should've mentioned the relation to E10S and sandboxing because as you suggest, it's complicated.
- E10S and sandboxing help 32 bit users as well as 64 and arguably offer the most immediate relief to the most users experiencing stability issues. Most of the folks I spoke with recommended tackling both of those before 64 if it comes to that.
- E10S and sandboxing are also more complicated and have a much longer time horizon to launch. Launching 64 bit first may be a stability bandaid for users who have 64 bit and adequate memory. It's also security boost for 64 bit users.
- Plugin work, as BDS says, is "hard and weird". E10S and 64 compete for the same engineers here.
- Add-ons are going to break in both projects. We need to take the developer community's pain into consideration.
Those are some big considerations to weigh in resource planning, product, developer community, and especially in engineering. This feels like the start of that conversation...
On Wednesday, June 4, 2014 1:32:48 PM UTC-4, Brian Smith wrote:
> On Tue, Jun 3, 2014 at 11:37 AM, Chris Peterson
>
- E10S and sandboxing help 32 bit users as well as 64 and arguably offer the most immediate relief to the most users experiencing stability issues. Most of the folks I spoke with recommended tackling both of those before 64 if it comes to that.
- E10S and sandboxing are also more complicated and have a much longer time horizon to launch. Launching 64 bit first may be a stability bandaid for users who have 64 bit and adequate memory. It's also security boost for 64 bit users.
- Plugin work, as BDS says, is "hard and weird". E10S and 64 compete for the same engineers here.
- Add-ons are going to break in both projects. We need to take the developer community's pain into consideration.
Those are some big considerations to weigh in resource planning, product, developer community, and especially in engineering. This feels like the start of that conversation...
On Wednesday, June 4, 2014 1:32:48 PM UTC-4, Brian Smith wrote:
> On Tue, Jun 3, 2014 at 11:37 AM, Chris Peterson
>
Tom Schuster
Jun 4, 2014, 2:46:02 PM6/4/14
to jmo...@mozilla.com, dev-pl...@lists.mozilla.org
> - Add-ons are going to break in both projects. We need to take the
developer community's pain into consideration.
What is the problem with addons and win64, binary addons? For e10s JS-only
developer community's pain into consideration.
addons are problematic as well, so the level of problems we can expect here
are quite different.
I don't think we should block win64 on e10s, because even estimating when
the project is going to ship to end-users is hard.
Cheers,
Tom
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
Chris Peterson
Jun 4, 2014, 5:05:31 PM6/4/14
to Brian Smith, dev-platform
On 6/4/14, 10:32 AM, Brian Smith wrote:
> Does it make sense to ship 64-bit Firefox before shipping
> mutli-process/sandboxed Firefox? I worry that 64-bit Firefox will be
> more memory hungry than 32-bit Firefox and if it lands first then it
> will be harder to land multi-process Firefox which is also likely to
> use more memory. I think having multi-process sooner is more important
> than having 64-bit sooner, if there is such a choice to make. IMO, it
> would be good to make explicit choices instead of just shipping
> whichever is done first.
I believe).
chris
Philip Chee
Jun 5, 2014, 8:36:26 AM6/5/14
to
On 04/06/2014 22:32, jmo...@mozilla.com wrote:
> We have a good understanding of the work required. The development
> work, as you might suspect, is largely done. We still produce 64 bit
> builds. The notable areas remaining are:
> - completing test coverage
> - working on plugin/add-on compatibility
> - writing/updating the installer
> - automating/augmenting/reallocating QA resources to support the
additional QA
> needs on an ongoing basis, and
> - some open product questions around how we roll it out, how we
announce and
> promote it, etc.
What it the status of our JIT code regarding 64 bit builds? ISTR that
> We have a good understanding of the work required. The development
> work, as you might suspect, is largely done. We still produce 64 bit
> builds. The notable areas remaining are:
> - completing test coverage
> - working on plugin/add-on compatibility
> - writing/updating the installer
> - automating/augmenting/reallocating QA resources to support the
additional QA
> needs on an ongoing basis, and
> - some open product questions around how we roll it out, how we
announce and
> promote it, etc.
the quality of our JIT code on 64 bits was one of the reasons for not
releasing official builds on those platforms.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Till Schneidereit
Jun 5, 2014, 8:59:54 AM6/5/14
to Philip Chee, dev-platform
On Thu, Jun 5, 2014 at 2:36 PM, Philip Chee <phili...@gmail.com> wrote:
> On 04/06/2014 22:32, jmo...@mozilla.com wrote:
>
> > We have a good understanding of the work required. The development
> > work, as you might suspect, is largely done. We still produce 64 bit
> > builds. The notable areas remaining are:
>
> > - completing test coverage
> > - working on plugin/add-on compatibility
> > - writing/updating the installer
> > - automating/augmenting/reallocating QA resources to support the
> additional QA
> > needs on an ongoing basis, and
> > - some open product questions around how we roll it out, how we
> announce and
> > promote it, etc.
>
> What it the status of our JIT code regarding 64 bit builds? ISTR that
> the quality of our JIT code on 64 bits was one of the reasons for not
> releasing official builds on those platforms.
>
We've been releasing 64 bit builds for Linux and OS X for years now.
> On 04/06/2014 22:32, jmo...@mozilla.com wrote:
>
> > We have a good understanding of the work required. The development
> > work, as you might suspect, is largely done. We still produce 64 bit
> > builds. The notable areas remaining are:
>
> > - completing test coverage
> > - working on plugin/add-on compatibility
> > - writing/updating the installer
> > - automating/augmenting/reallocating QA resources to support the
> additional QA
> > needs on an ongoing basis, and
> > - some open product questions around how we roll it out, how we
> announce and
> > promote it, etc.
>
> What it the status of our JIT code regarding 64 bit builds? ISTR that
> the quality of our JIT code on 64 bits was one of the reasons for not
> releasing official builds on those platforms.
>
Looking at arewefastyet.com, you can see that, depending on the exact
benchmark, we're either slightly faster or slightly slower on 32 bit than
on 64 bit. I don't see a reason why this should be different on Windows.
Robert Kaiser
Jun 5, 2014, 11:03:17 AM6/5/14
to
jmo...@mozilla.com schrieb:
variety of systems before claiming that.
bsmedberg and others have done some analysis that looks to me like our
OOM crashes (which are the largest group of stability issues nowadays)
are pretty split between cases where we run out of physical memory and
where we run out of VM space.
Now, 64bit gives us more VM space but probably also uses more physical
memory, so we could run out of physical memory even faster, even though
we should not run out of VM space. Also, given that every process has
its own VM space, e10s will help the VM space issues anyhow, so I wonder
how much impact on stability we'll have with 64bit anyhow after that.
> It's also security boost for 64 bit users.
Could someone please explain why you and Google claim 64bit to be more
secure? This is a new argument to me and I wonder what's behind it.
KaiRo
> Launching 64 bit first may be a stability bandaid for users who have 64 bit and adequate memory.
I would want to see decently founded comparative stats from a wide
variety of systems before claiming that.
bsmedberg and others have done some analysis that looks to me like our
OOM crashes (which are the largest group of stability issues nowadays)
are pretty split between cases where we run out of physical memory and
where we run out of VM space.
Now, 64bit gives us more VM space but probably also uses more physical
memory, so we could run out of physical memory even faster, even though
we should not run out of VM space. Also, given that every process has
its own VM space, e10s will help the VM space issues anyhow, so I wonder
how much impact on stability we'll have with 64bit anyhow after that.
> It's also security boost for 64 bit users.
secure? This is a new argument to me and I wonder what's behind it.
KaiRo
J. Ryan Stinnett
Jun 5, 2014, 11:34:21 AM6/5/14
to Robert Kaiser, dev-pl...@lists.mozilla.org
On Thu, Jun 5, 2014 at 10:03 AM, Robert Kaiser <ka...@kairo.at> wrote:
>> It's also security boost for 64 bit users.
>
>
> Could someone please explain why you and Google claim 64bit to be more
> secure? This is a new argument to me and I wonder what's behind it.
As stated in Google's announcement[1], the main security improvement
>> It's also security boost for 64 bit users.
>
>
> Could someone please explain why you and Google claim 64bit to be more
> secure? This is a new argument to me and I wonder what's behind it.
is (better) address space layout randomization. Even though that
exists in 32 bit too, it's more effective with 64 bit since the VM
space is so much larger. Looks like Windows has a specific "high
entropy"[2] version that's 64 bit only.
[1]: http://blog.chromium.org/2014/06/try-out-new-64-bit-windows-canary-and.html
[2]: http://blogs.technet.com/b/srd/archive/2013/12/11/software-defense-mitigating-common-exploitation-techniques.aspx
- Ryan
jmo...@mozilla.com
Jun 5, 2014, 12:31:48 PM6/5/14
to
These are two good questions Robert. Both points are nuanced and merit more discussion.
1. Re: 64 bit as a bandaid for OOM. This is an alternate viewpoint that a few folks advanced for discussion. I assumed this meant (at the least) PCs with > 4GB physical memory. I'm not sure if this applies to virtual memory. In addition to understanding the exact scenarios this might mitigate, ideally we'd have crashstats data to help us understand how big each of those scenarios is.
2. Re: Security. As Ryan said, it's about high-entropy ASLR in Windows 64 bit. I have a neophyte's understanding of JIT Sprays, this helped: http://blog.cdleary.com/2011/08/understanding-jit-spray/. Again, it would be nice to understand the magnitude of this particular threat.
On Thursday, June 5, 2014 11:34:21 AM UTC-4, J. Ryan Stinnett wrote:
1. Re: 64 bit as a bandaid for OOM. This is an alternate viewpoint that a few folks advanced for discussion. I assumed this meant (at the least) PCs with > 4GB physical memory. I'm not sure if this applies to virtual memory. In addition to understanding the exact scenarios this might mitigate, ideally we'd have crashstats data to help us understand how big each of those scenarios is.
2. Re: Security. As Ryan said, it's about high-entropy ASLR in Windows 64 bit. I have a neophyte's understanding of JIT Sprays, this helped: http://blog.cdleary.com/2011/08/understanding-jit-spray/. Again, it would be nice to understand the magnitude of this particular threat.
On Thursday, June 5, 2014 11:34:21 AM UTC-4, J. Ryan Stinnett wrote:
Eric Rescorla
Jun 5, 2014, 12:35:50 PM6/5/14
to J. Ryan Stinnett, Robert Kaiser, dev-platform
On Thu, Jun 5, 2014 at 8:34 AM, J. Ryan Stinnett <jry...@gmail.com> wrote:
> On Thu, Jun 5, 2014 at 10:03 AM, Robert Kaiser <ka...@kairo.at> wrote:
> >> It's also security boost for 64 bit users.
> >
> >
> > Could someone please explain why you and Google claim 64bit to be more
> > secure? This is a new argument to me and I wonder what's behind it.
>
See also: http://cseweb.ucsd.edu/~hovav/papers/sppgmb04.html
-Ekr
Even though that
> exists in 32 bit too, it's more effective with 64 bit since the VM
> space is so much larger. Looks like Windows has a specific "high
> entropy"[2] version that's 64 bit only.
>
> [1]:
> http://blog.chromium.org/2014/06/try-out-new-64-bit-windows-canary-and.html
> [2]:
> http://blogs.technet.com/b/srd/archive/2013/12/11/software-defense-mitigating-common-exploitation-techniques.aspx
>
> - Ryan
> On Thu, Jun 5, 2014 at 10:03 AM, Robert Kaiser <ka...@kairo.at> wrote:
> >> It's also security boost for 64 bit users.
> >
> >
> > Could someone please explain why you and Google claim 64bit to be more
> > secure? This is a new argument to me and I wonder what's behind it.
>
> As stated in Google's announcement[1], the main security improvement
> is (better) address space layout randomization.
Exactly.
> is (better) address space layout randomization.
See also: http://cseweb.ucsd.edu/~hovav/papers/sppgmb04.html
-Ekr
Even though that
> exists in 32 bit too, it's more effective with 64 bit since the VM
> space is so much larger. Looks like Windows has a specific "high
> entropy"[2] version that's 64 bit only.
>
> [1]:
> http://blog.chromium.org/2014/06/try-out-new-64-bit-windows-canary-and.html
> [2]:
> http://blogs.technet.com/b/srd/archive/2013/12/11/software-defense-mitigating-common-exploitation-techniques.aspx
>
> - Ryan
Ted Mielczarek
Jun 5, 2014, 2:48:33 PM6/5/14
to jmo...@mozilla.com, dev-pl...@lists.mozilla.org
On 6/5/2014 12:31 PM, jmo...@mozilla.com wrote:
> These are two good questions Robert. Both points are nuanced and merit more discussion.
>
> 1. Re: 64 bit as a bandaid for OOM. This is an alternate viewpoint that a few folks advanced for discussion. I assumed this meant (at the least) PCs with > 4GB physical memory. I'm not sure if this applies to virtual memory. In addition to understanding the exact scenarios this might mitigate, ideally we'd have crashstats data to help us understand how big each of those scenarios is.
>
There's definitely a virtual memory aspect that 64-bit builds make
> These are two good questions Robert. Both points are nuanced and merit more discussion.
>
> 1. Re: 64 bit as a bandaid for OOM. This is an alternate viewpoint that a few folks advanced for discussion. I assumed this meant (at the least) PCs with > 4GB physical memory. I'm not sure if this applies to virtual memory. In addition to understanding the exact scenarios this might mitigate, ideally we'd have crashstats data to help us understand how big each of those scenarios is.
>
better. Currently a 32-bit Firefox running on a 64-bit Windows install
has 4GB of address space to work with. A 64-bit Firefox running on
64-bit Windows has 8TB of address space (AIUI). We've seen plenty of
crashes due to virtual memory exhaustion, so 64-bit makes that much less
of an issue.
-Ted
0 new messages