- https://chromium-review.googlesource.com/c/chromium/src/+/3272411 enabled PartitionAlloc on macOS, but it was disabled in #31986 due to upgrade issues.

Here is @clavin's description of the problems encountered (copied from https://github.com/electron/electron/pull/31986#pullrequestreview-845868722 for ease of reference):
There's a large number of changes in this roll to do with PartitionAlloc specifically on mac, including specific initialization logic for registering the alloc zone and even doing an early "stubbing out" of sorts of the alloc zone, all on top of enabling the allocator on mac.

I found that Electron's mac build is set up somehow differently from Chromium's such that `//base` is depended on by both the main executable as well as the shared framework, whereas Chromium only depends on `//base` in the latter. This is sort of an issue for us because PartitionAlloc assumes it will only ever run once in a process<sup>1</sup>. That said, code added by the roll in PartitionAlloc checks if it can detect that it has already been registered and no-ops if that is the case, so theoretically there should be no harm done... but things still broke :/

And to dig into that last note more, I was seeing breakage in sqlite3 code that is more than a decade old because that sqlite3 code was querying the size of a past allocation and the allocator was returning `0`—I assume because the allocation sqlite3 was asking for was handled by a different allocator (system allocator? different partitionalloc? I wasn't sure how to diagnose that). My theory is that there was some subtle initialization race happening, either with static initializers or even just the time that partitionalloc loads (which is also a static initializer). Turning PartitionAlloc off resolved this specific issue. I'm not sure if there were more allocation anomalies like this or not, this was always the first to turn up if there were.

I was very intimidated by the idea of having to restructure the main electron binary on mac to not depend on `//base` as well as diagnose those allocator anomalies in the middle of an upgrade and felt like that work should be parallelized instead so this roll could land. I definitely think we should get PartitionAlloc working asap though.

Also of note, that note about the "situation with mas" is an error on my part. I remember reading in a comment of ParitionAlloc code something about hacky/private mac APIs, but looking back I couldn't find that comment. The patch's message should probably be updated to remove that and I should have left a lot more context when I wrote it—sorry about the loose end!


#### Notes

<sup>1</sup> There was a change in this roll where they decided to break this notion for `app_shim` in Chromium, though it sounds like they did it reluctantly and might change it in the future.

---

I sent this list of commits in the roll that informed this decision to Shelley over DM about a week ago, but I'll copy it here for more context:

<details>
<summary>Changes that informed this decision</summary>

* `[base/allocator] Do not register PartitionAlloc's zone twice.` ([commit](https://chromium.googlesource.com/chromium/src/+/9f8d3303f5aba9c5b4dd732d1409bc17a963a180)) — This affects mac only and codifies that “`//base` should never, ever be re-used in a dynamic library loaded into Chromium’s address space” (per the commit message).
* `Reland "base/allocator: Enable PartitionAlloc-Everywhere on macOS"` ([commit](https://chromium.googlesource.com/chromium/src/+/ec6b52f91a4cfa3fe28fd7cf2c3662efb1d55235)) — This tiny commit just turns on PartitionAlloc on macOS, which I basically undid in my patch.
* `[PartitionAlloc][mac] Undo the initialization race fix.` ([commit](https://chromium.googlesource.com/chromium/src/+/3f102ce68f35817e11aac7332f37a6a8c2123143)) — Included this for extra context.
* `[PartitionAlloc][mac] Solve initialization race.` ([commit](https://chromium.googlesource.com/chromium/src/+/adcda7775ad5f7d99b01c25aea8e9b7f45d5be65)) — There’s a lot in this one commit, but essentially the PartitionAlloc init on mac now requires calling a function in a file in `//base` (but without depending on `//base`) at the start of `main` to register a dummy alloc zone that gets replaced with the real PartitionAlloc later. Another reference to how “Chromium’s main executable must not depend on `//base`, so the code is added in a fairly roundabout way.” Notably, it is expected that the main framework (Electron Framework in our case) is the one to depend on `//base` and init the real PartitionAlloc.
* `[PartitionAlloc] Extend early PartitionAlloc init to content_shell.` ([commit](https://chromium.googlesource.com/chromium/src/+/5cf6a10148fad105570462de6fec8babffa10467)) — Just adds the above commit’s early init setup to content_shell.
* `[PartitionAlloc] Allow double zone registration on mac for app_shim.` ([commit](https://chromium.googlesource.com/chromium/src/+/2173ca15b020fdde7b9fedb3b7eae65bceaad2c0)) — Contrary to all the advice to not depend on `//base` in the app executable, this commit makes it possible to register PartitionAlloc twice in exactly that way. This is sort of implemented as a workaround to not having to refactor app_shim: “The ideal solution is to not depend on `//base` in the shim. A workaround is to allow the library to also register a zone.”
* **Note**: there’s a handful more commits in this roll that pertain to PartitionAlloc, these are just the most important ones I could remember.
* Concern about MAS build: I just did a double check bc I thought I remember seeing a comment in one of these files about a private or obscure API, but I can’t find it anymore so this concern can be stashed away for now as a non-issue.
* Running safely: Given the context of all the above commits, it’s clear to me that the Electron build needs to be a little bit restructured to initialize PartitionAlloc correctly. Currently, it is being double registered (once by the main executable that depends on `//base` and a second time by the Electron Framework), which is usually a non-issue because PartitionAlloc can usually detect itself and stop the second init. That said, the timing is still wrong and I was consistently getting errors in decade-old or more sqlite3 code that was crashing because it was trying to query the size of a past allocation and that query was returning 0. I assume this could be one of many similar bugs due to the initialization being not quite right. I tried adding the early init with no luck in this case, and I couldn’t figure out a quick way to fix the main exec’s dependency on `//base`.

</details>
shell/app/electron_main.h
#ifndef ELECTRON_SHELL_APP_ELECTRON_MAIN_H_
#define ELECTRON_SHELL_APP_ELECTRON_MAIN_H_
#include "content/public/app/content_main.h"
#endif