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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
> 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.
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.
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(!)
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.
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.
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 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.
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.
Have they fixed the "Google Chrome Helper: CoreText CopyFontsForRequest received mig IPC error (FFFFFECC) from font server" error that has been around forever?
(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.
(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.)