how long are we continuing 32-bit OS X support?

[Nathan Froyd]

[Not sure if this is strictly dev-platform material; dev-planning might have been more appropriate in some respects.]

Our Firefox builds for OS X currently build a 32-bit version, a 64-bit version, and then squash those together to produce a universal binary that runs on 32-bit or 64-bit systems, as appropriate. This method of building is somewhat wasteful, as we're building a decent chunk of stuff (chrome JS, etc.) that is architecture independent.

When targeting OS X, native or cross, clang supports compiling for multiple architectures in a single pass. Being able to use this capability would likely speed up our TBPL OS X builds somewhat. (Slowdown in actual compilation would likely be compensated for by not having to build chrome jars twice, install headers twice, etc. etc.) However, a variety of issues block being able to do this, mostly related to a number of places the code where decisions are made based on whether configure thought we're compiling for a 32-bit or 64-bit architecture.

I've started poking at some of these issues (bug 925167 and dependents if you're interested). But various people have pointed out that it only makes sense to devote resources to this if we're going to be keeping 32-bit OS X support alive for some time to come. Otherwise, we can just wait a short amount of time for 32-bit support to be dropped and these issues go away.

How long do we intend to continue shipping a 32-bit Firefox binary on OS X? As I understand it, we're doing this solely for our OS X 10.6 users, as they are the only ones potentially running OS X on non-64-bit capable machines.

-Nathan

[Gijs Kruitbosch]

Additional reason to discuss: this may also affect decisions about how
to ship ICU data, at least on OS X, because it's currently being
duplicated, too.

~ Gijs

[Ehsan Akhgari]

Note that we also use this to support 32-bit plugins, so our target
audience is not just 10.6 users.

Cheers,
Ehsan

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Mike Hommey]

On Mon, Oct 21, 2013 at 08:24:15AM -0700, Nathan Froyd wrote:
> How long do we intend to continue shipping a 32-bit Firefox binary on
> OS X? As I understand it, we're doing this solely for our OS X 10.6
> users, as they are the only ones potentially running OS X on
> non-64-bit capable machines.

Note OS X 10.6 runs in 32-bit mode *by default*, even on *64-bit
capable* hardware. That's the whole problem. There are only a few
Macbook models that aren't 64-bit capable. There are much more OSX
installs that run in 32-bit mode.

Mike

[Chris Peterson]

On 10/21/13 3:28 PM, Mike Hommey wrote:
> Note OS X 10.6 runs in 32-bit mode*by default*, even on *64-bit

> capable* hardware. That's the whole problem. There are only a few
> Macbook models that aren't 64-bit capable. There are much more OSX
> installs that run in 32-bit mode.

But the "boat anchor" is still OSX 10.6, not the hardware? If we drop
10.6, can we assume all 10.7 and 10.8 users are running in 64-bit mode?


cpeterson

[Mike Hommey]

AFAIK, running 10.7+ in 32-bit mode is something you have to do manually
at boot time. I guess nobody does that except for testing purpose. Also,
afaik 10.7+ doesn't support 32-bit-only mac hardware.
That leaves the problem of running 32-bit-only plugins. Do we have data
on this? Are there still 32-bit-only plugins around, on 10.7+ systems?
If there are and we still need to support them despite dropping 10.6
(which I'm not advocating, but i understand it'd be an option), I wonder
if it would be possible, and how much work it would be, to make the
plugin-container not use libxul at all, and just be a small shim doing
ipc calls. But I really don't know what the plugin container currently
does on its end that requires libxul code besides ipc. If that were
possible, that would also be something useful for a possible future
switch to gtk3, where plugins use gtk2 and both can't be loaded in the
same process, so gtk2 plugin with gtk3 libxul doesn't work.

Mike

[Hubert Figuière]

No. it is the non 64-bits compatible hardware the 10.6 still supports.
The first Intel Mac still run ia32.


Hub

[Hubert Figuière]

On 21/10/13 07:27 PM, Mike Hommey wrote:
> AFAIK, running 10.7+ in 32-bit mode is something you have to do manually
> at boot time. I guess nobody does that except for testing purpose. Also,
> afaik 10.7+ doesn't support 32-bit-only mac hardware.

You are confusing the kernel vs the userland. If the CPU is 64-bits
capable you can run apps in 64-bits when they have been compiled for it.

Proof: on 10.6 on a Core 2 Duo, apps can run in 64-bits if it is
provided (I have Aperture and Lightroom to prove it) but the kernel
still runing in 32-bits.

Bottom line: as long as we want to support 10.6 we have to provide
32-bits binaries.

Hub

[Philip Chee]

On 22/10/2013 01:14, Ehsan Akhgari wrote:
> Note that we also use this to support 32-bit plugins, so our target
> audience is not just 10.6 users.

I thought we recently removed 32-bit plugin support on OS X.

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.

[Gavin Sharp]

We removed the feature that allows users to easily restart in 32-bit
mode in https://bugzilla.mozilla.org/show_bug.cgi?id=850925 (Firefox
22).

Gavin

[Henri Sivonen]

On Mon, Oct 21, 2013 at 8:14 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> Note that we also use this to support 32-bit plugins,

For reference, even though Flash and Java are 64-bit on Mac, notable
32-bit plug-ins include:
* Silverlight (DRM for Netflix)
* Widevine Media Optimizer (DRM for HBO Nordic)
* Google Talk (WebRTC surrogate for Google Hangouts)

In theory at least, it should be possible to create a smaller 32-bit
plug-in host, though.

> so our target audience
> is not just 10.6 users.

s/10.6/first Intel Mac Mini and first MacBook/, right? 10.6 on 64-bit
CPUs runs 64-bit apps even when the kernel runs as 32-bit.

--
Henri Sivonen
hsiv...@hsivonen.fi
http://hsivonen.fi/

[Hubert Figuière]

On 22/10/13 07:54 AM, Henri Sivonen wrote:
>> so our target audience
>> > is not just 10.6 users.
> s/10.6/first Intel Mac Mini and first MacBook/, right? 10.6 on 64-bit
> CPUs runs 64-bit apps even when the kernel runs as 32-bit.

Yes. That's the case.

Hub

[Georg Fritzsche]

On Oct 22, 2013, at 1:27 AM, Mike Hommey <m...@glandium.org> wrote:

> If there are and we still need to support them despite dropping 10.6
> (which I'm not advocating, but i understand it'd be an option), I wonder
> if it would be possible, and how much work it would be, to make the
> plugin-container not use libxul at all, and just be a small shim doing
> ipc calls. But I really don't know what the plugin container currently
> does on its end that requires libxul code besides ipc.

I'm not sure on what parts are all involved, but that should be a good size win.
I wonder if there is anything preventing us from using the same approach for
the eventual Win64 builds?

Georg

[Mike Hommey]

On Mon, Oct 21, 2013 at 10:00:13PM -0400, Hubert Figuière wrote:
> On 21/10/13 07:27 PM, Mike Hommey wrote:
> > AFAIK, running 10.7+ in 32-bit mode is something you have to do manually
> > at boot time. I guess nobody does that except for testing purpose. Also,
> > afaik 10.7+ doesn't support 32-bit-only mac hardware.
>
> You are confusing the kernel vs the userland. If the CPU is 64-bits
> capable you can run apps in 64-bits when they have been compiled for it.
>
> Proof: on 10.6 on a Core 2 Duo, apps can run in 64-bits if it is
> provided (I have Aperture and Lightroom to prove it) but the kernel
> still runing in 32-bits.

This is interesting. I just checked and all apps on my wife's 10.6 mac
are indeed running in 64-bits mode, including Firefox. That must have
changed in some 10.6.x because i'm sure this wasn't the case last time I
checked, which was a long time ago.

Mike

[Armen Zambrano G.]

Releng note: if we stop it, we could also get much better test capacity
on tbpl as we could re-purpose our 10.6 test infrastructure.

cheers,
Armen

[Armen Zambrano G.]

Releng note: if we stop it, we could also get much better test capacity
on tbpl as we could re-purpose our 10.6 test infrastructure.

cheers,
Armen

On 2013-10-21 1:14 PM, Ehsan Akhgari wrote:

[Chris Peterson]

On 10/22/13, 4:54 AM, Henri Sivonen wrote:
> On Mon, Oct 21, 2013 at 8:14 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>> Note that we also use this to support 32-bit plugins,
>
> For reference, even though Flash and Java are 64-bit on Mac, notable
> 32-bit plug-ins include:
> * Silverlight (DRM for Netflix)
> * Widevine Media Optimizer (DRM for HBO Nordic)
> * Google Talk (WebRTC surrogate for Google Hangouts)

Silverlight is EOL'd, so it sounds like we need to maintain a 32-bit
plug-in process as long as Netflix uses Silverlight. :(

> s/10.6/first Intel Mac Mini and first MacBook/, right? 10.6 on 64-bit
> CPUs runs 64-bit apps even when the kernel runs as 32-bit.

Do we have Telemetry or FHR data about how many Firefox users are using
OS X 10.6, first Intel Mac Mini, or first MacBook?


cpeterson