commit 4ebd0722856c86d339a13242bb2f5de77466895a
author Mark Mentovai <mark@chromium.org> Sat Sep 19 00:36:05 2020
committer Commit Bot <commit-bot@chromium.org> Sat Sep 19 00:36:05 2020
tree 18b6aba95633689e083b9b4946ba230f2cc33ad8
parent 67d631134298a95377ba9804742d0bc55bb22292

mac: Make the system page size a run-time property

This enables x86_64 Chrome to run under Rosetta binary translation on
arm64 macOS systems.

The system page size is no longer considered a compile-time constant on
macOS. It may be determined dynamically at run time through the
vm_page_size variable. The related vm_page_shift and vm_page_mask
variables are also available.

On arm64, the system page size is currently 16kB. On x86_64, it’s 4kB.
x86 code running translated on currently available arm64 systems (the
Apple Developer Transition Kit) is subjected to the arm64 system’s
native 16kB page size, meaning that code built with an expectation of
4kB pages, previously correct for native x86_64, will not work correctly
in the translated environment. This is significant because the DTK is
the only mac-arm64 system available for testing now, and it’s become
important to test x86_64 Chrome under Rosetta translation on arm64.

To overcome this limitation, the system page size and related constants
are, on macOS, made to be determined at run time on the basis of the
variables provided for this purpose by the system.

In order to make this change without violating Google’s and Chrome’s
prohibition against load-time initializers, the variables that had been
used to convey page size information need to become functions. On all
platforms except for macOS, the functions remain constexpr, are marked
to be always inlined, and continue to return the same compile
time-determined value they had in the past, so while it appears
invasive, this change is in fact physically a no-op on these platforms.
On macOS, it is a functional no-op change, except when running x86_64
code on arm64 under Rosetta translation, where it causes correct values
to be used for the run-time environment.

Adopting a compile-time 16kB page size on mac-x86_64 was considered but
rejected due to the potential for memory footprint and performance
impact. That approach would result in a behavior change for native
x86_64 users, which constitute the vast majority of consumers of the
x86_64 build, for the benefit of the comparatively small number of arm64
users running x86_64 Chrome under translation. This is undesirable,
particularly for a change that may need to be merged to more stable
branches.

Apple documentation links:

https://download.developer.apple.com/Documentation/Universal_App_Quick_Start_Program_Resources/DTK_Release_notes.pdf

“Rosetta 2 Behaviors…Applications that depend on a 4K memory page size
will not run. Examples of this may include some web browsers and
language runtimes.”

Also:

https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code#3616877
https://developer.apple.com/videos/play/wwdc2020/10214/?time=544 (9:04)

Bug: 1102194
Code-Word: disaster
CQ-Include-Trybots: luci.chromium.try:mac-arm64-rel
Change-Id: I143f38f06444f96eb8a82ede34f2a44ea48318fb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2361202
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Benoit L <lizeb@chromium.org>
Reviewed-by: Chris Palmer <palmer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#808610}