Yesterday’s Mac canary was 64-bit

[Mark Mentovai]

We’re back to 32-bit today, but yesterday’s Mac canary (33.0.1702.2) was quietly released as 64-bit to help shake out any problems with the 64-bit Mac build, as we move closer to releasing it more widely.

So far, we’ve noticed two problems:

• http://crbug.com/316401 — Native Client doesn’t work, although it seems to work properly in an unofficial build at the same revision.
  
• In crash reports, symbols for system libraries are missing (we just need to upload them) and while most walked stacks are fine, a small number seem implausible.

Another known limitation is that the 64-bit browser will not load 32-bit plug-ins. We’re evaluating whether it needs to. On the other hand, the 64-bit browser is able to load 64-bit plug-ins that the 32-bit browser could not, such as the Java 7 plug-in.

If you have any additional feedback about yesterday’s canary, please let me know. After evaluating all of the feedback, I plan to release 64-bit builds to the canary channel somewhat more regularly.

If you’re interested in using the 64-bit build in your own development, set the target_arch and host_arch GYP variables both to “x64” and run “gclient runhooks”. You can do this by setting the GYP_DEFINES environment variable to "target_arch=x64 host_arch=x64".

Mark

[Mark Seaborn]

NaCl/PNaCl might have a couple of problems with switching between 32-bit and 64-bit on the same system:

 * The PNaCl translation cache doesn't include the architecture in the cache key.  So if you run a pexe on 32-bit Chromium, then switch to 64-bit Chromium, PNaCl will still try to run the 32-bit nexe (which will fail) rather than re-translating for 64-bit.  Derek Schuff is looking into this.

 * When Chromium downloads the PNaCl translator, it downloads the build for the current architecture.  If the Mac build switches from 32-bit to 64-bit, Chromium will delete the x86-32 build of the translator and download the x86-64 build, and vice-versa if Chromium switches back to 32-bit.  This doesn't affect correctness, but it might lead to excessive re-downloading of the same files.  Maybe we can improve this so that PNaCl will keep copies of the x86-32 and x86-64 translators side by side.

Cheers,

Mark

[Mark Mentovai]

Mark Seaborn wrote:

NaCl/PNaCl might have a couple of problems with switching between 32-bit and 64-bit on the same system:

 * The PNaCl translation cache doesn't include the architecture in the cache key.  So if you run a pexe on 32-bit Chromium, then switch to 64-bit Chromium, PNaCl will still try to run the 32-bit nexe (which will fail) rather than re-translating for 64-bit.  Derek Schuff is looking into this.

 * When Chromium downloads the PNaCl translator, it downloads the build for the current architecture.  If the Mac build switches from 32-bit to 64-bit, Chromium will delete the x86-32 build of the translator and download the x86-64 build, and vice-versa if Chromium switches back to 32-bit.  This doesn't affect correctness, but it might lead to excessive re-downloading of the same files.  Maybe we can improve this so that PNaCl will keep copies of the x86-32 and x86-64 translators side by side.

Are there bugs for either of these that I can watch?

[Jan Voung]

Actually there is a bug for the second item: https://code.google.com/p/chromium/issues/detail?id=316911, not just a bandwidth issue. CC'ed you there.

[Derek Schuff]

I just filed https://code.google.com/p/chromium/issues/detail?id=316912 for the first item.

On Fri, Nov 8, 2013 at 2:09 PM, Derek Schuff <dsc...@google.com> wrote:

I just filed https://code.google.com/p/chromium/issues/detail?id=316912 for the first item.

[Mark Mentovai]

Thanks. I hung the newly-filed http://crbug.com/316916 off of these as dependencies. It’s tracking bug to tie up everything that we learned from this initial canary, so that we can make sure we have an answer for the known issues before trying again.

[Jan Voung]

+cc asargent

Oh one other worry was Multi-CRX extensions with "_platform_specific/" directories. Do they get re-installed too?