Build Config

PartitionAlloc's behavior and operation can be influenced by many different settings. Broadly, these are controlled at the top-level by GN args, which propagate via buildflags and #defined clauses.

Most of what you'll want to know exists between

• //base/allocator/partition_allocator/BUILD.gn,
• Everything else ending in .gn or .gni in //base/allocator/partition_allocator/,
• allocator.gni,
• //base/allocator/BUILD.gn, and
• //base/BUILD.gn.

While Chromium promotes the #if BUILDFLAG(FOO) construct, some of PartitionAlloc's behavior is governed by compound conditions #defined in partition_alloc_config.h.

PartitionAlloc targets C++17. As the team develops standalone PartitionAlloc, this may diverge from what the rest of Chrome browser does, as we will be obligated to support external clients that may not yet support newer C++ standards.

See Chrome-External Builds for more.

Select GN Args

use_partition_alloc

Defines whether PartitionAlloc is at all available.

Setting this false will entirely remove PartitionAlloc from the Chromium build. You probably do not want this.

Back when PartitionAlloc was the dedicated allocator in Blink, disabling it was logically identical to wholly disabling it in Chromium. This GN arg organically grew in scope with the advent of PartitionAlloc-Everywhere and must be true as a prerequisite for enabling PA-E.

use_partition_alloc_as_malloc

Does nothing special when value is false. Enables PartitionAlloc-Everywhere (PA-E) when value is true.

• While “everywhere” (in “PartitionAlloc-Everywhere”) tautologically includes Blink where PartitionAlloc originated, setting use_partition_alloc_as_malloc = false does not disable PA usage in Blink, which invokes PA explicitly (not via malloc).
• use_partition_alloc_as_malloc = true must not be confused with use_partition_alloc (see above).

Notable Macros

There is an ongoing effort to break out PartitionAlloc into a standalone library. Once PartitionAlloc stands alone from the larger Chrome build apparatus, the code loses access to some macros. This is not an immediate concern, but the team needs to decide either

• how to propagate these macros in place, or
• how to remove them, replacing them with PA-specific build config.

A non-exhaustive list of work items:

• OFFICIAL_BUILD - influences crash macros and PA_THREAD_CACHE_ALLOC_STATS. These are conceptually distinct enough to be worth separating into dedicated build controls.
• IS_PARTITION_ALLOC_IMPL - must be defined when PartitionAlloc is built as a shared library. This is required to export symbols.
• COMPONENT_BUILD - component builds (as per //docs/component_build.md) must #define COMPONENT_BUILD. Additionally, to build Win32, invoker must #define WIN32.
• MEMORY_TOOL_REPLACES_ALLOCATOR
• *_SANITIZER - mainly influences unit tests.

Over time, the above list should evolve into a list of macros / GN args that influence PartitionAlloc's behavior.