Chrome for Mac 64-bit Support | Hacker News Reader

Chrome for Mac 64-bit Support

code.google.com

182 pointsadambware79 comments

Oh, wow, didn't know that Chrome was still 32-bit on Macs. The Linux builds have been 64-bit since early 2009, and Windows went 64-bit earlier this year. Congrats to the Chrome team. :)

(FWIW, Firefox has been 64-bit on OS X and Linux since 4.0, but we're still working on Win64 support. Of course, Microsoft kicked everyone's ass when they released Windows XP Professional x64 Edition in 2005, which included a 64-bit version of IE6.)

From what I have read, for software which wasn't originally developed for Windows, especially if the code base is old enough, porting to 64-bit is harder on Windows than on other systems.

The problem is that, while the Unix-based world went the LP64 way (int is 32-bit, long and pointers are 64-bit), Windows went the LLP64 way (int and long are 32-bit, pointers are 64-bit). A lot of Unix programmers tended to behave as if "long" was the largest native type ("long long" on 32-bit uses a pair of registers). They have to scrub their whole code base for things like assuming an object's size or array index will always fit on a "long".

For software originally developed for Windows, LLP64 was supposed to make porting easier, since unlike on the Unix world (where "long" could be 32-bit or 64-bit), a lot of Windows programs assumed a LONG was always 32-bit, and that assumption was baked into file formats and IPC protocols.

Newly developed software has it easier; programmers nowadays keep in mind that there are relevant systems where sizeof(long) < sizeof(size_t), and since the C99 standard they have the stdint.h types to help (even on Windows with its pre-C99 compilers, since it's easy to find a working stdint.h for them).

----

As for Mac OS X, the porting problem is Carbon. If the code base is old enough, it'll be using Carbon, which AFAIK is not available for 64-bit.

Congrats to the team for doing something many many years late?

This also fixes the Java 8 support in Chrome on Mac, which didn't work because Java 8 only supported 64-bit browsers:

https://www.java.com/en/download/faq/chrome.xml

For those of us that still need to access legacy systems (routers, switches, etc.) that have Java interfaces, this is a pretty major upgrade.

I stopped using Chrome because of the java issue. It showed quite clearly that Google has zero regard for Mac users and their concerns

Not really. A lot of people at Google are on Macs. I think it's more that the Chrome team doesn't prioritize Java support, which I think shows their priorities are pretty much in order.

The "well, now that the last 32 bit app on your Mac gets with the times, life's gonna be better" comment shows (a) this wasn't just about Java, and (b) they knew they're way behind the times.

For one, it's far from the "ast 32 bit app" on the Mac.

Second, even some Apple apps took some years to be released as 64 bit after the transition.

Third, it's not like 64 bit apps get some magic cookies and unicorn love. Millions of Mac users used 32bit Chrome just fine and didn't even know about it (being 32bit).

At the moment, the only thing keeping 32 bit frameworks resident on my Mac is Dropbox. I'm sure there's plenty of legacy apps out there, but it looks to me like it's not that common anymore.

As a Linux user, I find this quite humorous.

More like it showed quite clearly that Google has zero regard for Java browser plugin users and their concerns.

Can someone explain why this wasn't done long ago? What are the difficulties of putting out a 64 bit build?

I know for a long time there was an issue with Flash not supporting 64 bit browsers (and a browser without flash was hard to sell)

I don't think this is a real issue? (64-bit firefox supported 32-bit flash, at least on Linux).

That can't possibly be the issue. Plugins like Flash run in a separate process, which can remain 32-bit if required to do so by the plugin while the browser itself goes 64-bit.

Possibly all the Webrtc stack ?

2009! They thought they could get it done in time for Snow Leopard GM!

Apparently, Mac OS X isn't exactly a priority for them.

I think that for most purposes 32 bit had worked without much issue so it's a matter of cost vs benefit. Can you think of any issues that people face because Chrome was 32 bit? So far I'm seeing Java 8 integration, which is probably a tiny fraction of their users. Also it's not really breaking since those users can just use Firefox for that purpose. They obviously don't consider this a loss.

This is true for almost any application (very few things NEED 64 bits).

Security is a big one. 64-bit address spaces are inherently harder to exploit, plus, IIRC, on OS X in particular, ASLR in 32-bit processes has some weaknesses that were never fixed.

Good point! To stay on my angle, are there Chrome specific security bugs that are in the most recent builds that are exacerbated by 32bit builds?

Or, you know, 64 bit for a single platform isn't exactly a lifechanger they should devote their resources in.

So wait - I downloaded the 64 bit 39.0.2171.65 version. Because of this, I finally updated my Java version (now 8.25). I still can't java applets to run in Chrome. What gives? I still get Verify Java Version32-bit Chrome does not support Java 7 and later versions on Mac OS X. Java runs only on 64-bit browsers.

http://javatester.org/version.html Gives an error - Java needs your permission to run, but I've already allowed in Java control panel. Ideas?

Try going to System Settings and then the Java control panel. Locate the Java applet runtime configuration and make sure it's pointing to Java 8 and not some random Java 7 applet runtime the upgrade left behind. Java has system wide preferences for runtimes of both the full JRE and the plugin, separately.

Failing that, go to java.com and see what their check says.

Hi- Already tried both. Anyone able to ACTUALLY get Java 8 running on Chrome 64bit?

   #73 mark@chromium.org
   This was released to the stable channel today in version 39.0.2171.65. 
   Thanks for your patience, everyone.
   Status: Fixed

> Thanks for your patience, everyone.

5 years and 3 months after the issue was opened...

    damurdock$ file /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome 
    /Applications/Google Chrome.app/Contents/MacOS/Google Chrome: Mach-O executable i386
    damurdock$ file /Volumes/Google\ Chrome/Google\ Chrome.app/Contents/MacOS/Google\ Chrome 
    /Volumes/Google Chrome/Google Chrome.app/Contents/MacOS/Google Chrome: Mach-O 64-bit executable x86_64

Top is my currently installed Chrome, bottom is freshly downloaded from Google. Looks like it's time to update!

If I have the 32 bit Chrome, do I need to install a new version, or will updates going forward give me the right architecture?

I can't imagine they'd force people to use 64 bit via an update.

It's customary to give the option.

http://www.chromium.org/getting-involved/dev-channel

Is there any point to giving the option for OSX? When was the last OSX version that did not support 64bit? Is there any reason to prefer a 32bit version on an OSX that supports 64bit?

Real questions, not rhetorical!

If I look at http://www.chromium.org/getting-involved/dev-channel , they list a Windows 32-bit channel and separate 64-bit channel, but only one Mac channel. I'm not sure if this means anything about their release intentions, or if the page may still be updated.

OS X has supported x86_64 applications since 10.5 (Leopard), so there's no problem there if your CPU supports it; moreover, the last OS X release to support 32-bit-only x86 CPUs was 10.6 (Snow Leopard). However, Chrome does support 10.6, so I guess this release may have the effect of dropping support for some Mac models from 2006 that previously worked.

It's customary to give the option when there's an option. If you go to the Chrome download page, there is no longer any option to download the 32-bit version.

I just checked chrome://chrome for updates and it confirmed there was no update and 38 was the latest, but when I re-downloaded chrome from https://www.google.com/chrome/browser/ it was the 64-bit v39 - so yes you do need to install a new version!

When you download the new browser, does all of your preferences like bookmarks and extensions and stuff transfer over?

Yes.

What about if you had pages open that you don't want to lose (literally hundreds of tabs)?

you can right click on a tab to bookmark all tabs to be safe.

> What about if you had pages open that you don't want to lose (literally hundreds of tabs)?

There's always one of these in every discussion about a web browser. That one person who, instead of bookmarking things, keeps literally hundreds of tabs open.

(Some of my best friends are "this guy")

Then you should first change your browsing habbits, and probably several other ways in which you organize things in general. And ask yourself if you really understand modern technology.

Second, you could save all the open tabs as bookmarks, with the Bookmarks -> Bookmark all Tabs command. It will save all open tabs in a new bookmarks folder.

Lastly, when you reopen the browser after the update, you can click File -> Reopen closed tabs, which will reopen all of those, even if you haven't bookmarked them.

Why not save open tabs as bookmark folder? Then reopen the bookmark folder as a tab-set? I know you can do this with FF (maybe +ext).

I use OneTab[1] to dump tab state.

[1] https://chrome.google.com/webstore/detail/onetab/chphlpgkkbo...

As far as I can tell, once you've downloaded the 64-bit app, you can launch it instead of the older version and it's an exact drop-in replacement. For example, all my open tabs were restored in the 64-bit process, as they had been in the 32-bit one.

I had the exact same issue:

Oddly enough, chrome didn't want to auto-update to this, it was "up-to-date" at 38.x, even quitting and relaunching applied no change. Downloading a fresh `dmg` archive from https://www.google.com/chrome/browser/ applied the 64-bit update.

But that doesn't make sense - if it's true that they will not be providing a 32bit version for Mac from now on. Then most people will be stuck on version 38.

I doubt they'd stop updating users just because of this change. It's more likely that they roll out the auto-upgrade in stages, rather than having everyone update all at once.

Mine just updated to version 39 and it got the 64-bit support.

Just to confirm, if I wait, the updater will grab version 39 x64 eventually, it just takes time to rollout.

Yes.

Can anyone here explain the benefits of upgrading to this versus using v38 (32 bit)? Battery life? Less RAM usage? Faster?

Faster, able to use more memory more efficiently. More ram usage.

With current ram sizes this might be negligible, but 32bit chrome would have to load 32bit versions of all system frameworks, while you have 64bit in memory all the time. The less 32bit apps you have, the better :)

I imagine this might affect startup times too? I.e. you are likely to have the 64bit frameworks already in memory while you have to load 32bit from disk when starting chrome.

(Chrome startup is so slow on my machine that this might be negligible anyway).

Yes you're right. At the same time, you probably have some other 32bit apps that forced those libs to load, e.g. Dropbox, which is still 32bit and starts with the system.

It ought to work with Handoff and let you open iOS Safari's current web page in Chrome. Currently you get a popup with the Chrome icon but it doesn't work because Chrome isn't 32-bit(!)

I thought that Handoff was broken. Still broken in the sense that no error message is shown for an invalid exchange.

If you have previously installed Chrome via Homebrew Cask (http://caskroom.io), you can force an update to 39.x by running brew cask install google-chrome --force

Hopefully now they can resolve the issues that lead to Chrome having significantly less smooth scrolling than Safari and reducing the battery life of my MBP from ~8 hours to ~5 hours.

Finally! Tested and it works well with the Java 7 plugin. Somehow this Java verification page still doesn't work: https://www.java.com/en/download/installed.jsp

The requirement for 64 bit support for SSL VPNs has always required I live a hybrid world on the Mac - browsing with Chrome, and launching 64-bit firefox to connect to VPNs. It will be interesting to see if I can live in an all chrome world if I chose.

Huh, what VPN software do you use that cares about the architecture of your browser? Is this an NPAPI plugin?

Java (Juniper, etc. SSL VPN clients). Java 32-bit was broken/not available/too old/whatever. 64-bit java required a 64 bit browser.

Just checking.. does the page https://dev.twitter.com/ load for those who've upgraded to the 64-bit OSX Chrome? Reliably crashes for me now..

seems to work fine for me. 10.6

Thanks.. figured it was something local but I appreciate the sanity check.

Is this build more easier on the battery life? I tried Chrome Canary a few weeks ago and just scrolling down a page used up much more resources than Safari.

I wonder how this will affect Chrome's impact on the battery. My OSX already complains that Chrome "uses significant energy."

There's something terrifying about a web browser needing more than four gigabytes of memory.

x86-64 programs run faster regardless of how much memory they use because they get access to more registers. There’s also the issue that loading a 32-bit application when everything else running is 64-bit requires loading 32-bit versions of all the libraries it uses, so ideally at some distang point in the future, all applications will be 64-bit.

Clearly if Chrome had needed the memory, this would have been implemented long ago.

I was using 64 bit for about a week until only just a couple of days ago. It crashed often and in between crashes it kept popping up windows saying that pages were non-responsive (if I want to "wait" or "kill"). Some were actually unresponsive, others were responsive. Unless they fixed these major issues in only the last couple of days, I'm sticking with 32 bit.

FWIW, I'm on the beta channel and have been using 64 bit for a month or more with no issues or crashes whatshoever.

Will I need to reinstall chrome or will it auto update to a 64bit version?

Just install Chrome beta or canary, by overwriting your existing installation in /Applications and you're all set.

Have they fixed the "Google Chrome Helper: CoreText CopyFontsForRequest received mig IPC error (FFFFFECC) from font server" error that has been around forever?

I wonder why it took so much longer on OS X than Linux?

(I worked on Linux Chrome back in the era when this change was made.)

64-bit was important on Linux because the system libraries that Chrome uses were increasingly unavailable in 32-bit versions on 64-bit systems.

On other platforms, while there are advantages to 64-bit binaries, those advantages haven't outweighed the other useful things you could be spending engineering time on.

for the love of God finally!

Reply on news.ycombinator.com