Re: Binary Size Impact of Enabling Sized Deallocation in PartitionAlloc

Stephen Nusko

unread,

Nov 18, 2025, 11:22:05 PMNov 18

to Ayumi Ono, binar...@chromium.org, le...@google.com, chrome-m...@google.com, chrome-mem...@google.com, Hans Wennborg

Once more, apparently you have to be a member :)

On Tue, Nov 18, 2025 at 10:19 PM Stephen Nusko <nus...@google.com> wrote:

+binar...@chromium.org, Apparently interns can't email non @google.com accounts (even chromium.org ones) without an exception. So re-adding this mailing list in until we fix that.

On Tue, Nov 18, 2025 at 9:34 PM Ayumi Ono <ayum...@google.com> wrote:
TL;DR; Chrome’s PartitionAllocis working on enabling sized deallocation. We’ve found large binary size increases and would like to ask lexan folks if clang is configured correctly (we see some strange additional assembly instructions), and binary-size folks if they have ideas to reduce the size further or if we could accept the binary hit for different platforms. Context below.
Feature: Sized Deallocation
Currently on asan builds we have enabled sized deallocation by removing the -fno-sized-deallocation compiler flag, which allows the compiler to use operator delete(void* ptr, size_t size).
In PartitionAlloc, these calls are redirected via ShimCppDeleteWithSize to our custom FreeWithSize function.
FreeWithSize is implemented to directly utilize the provided size argument for deallocation logic (e.g., calculating bucket_index), instead of needing to read metadata from the allocated pointer.
Observed Android Binary Size Increase:
CL Patch 18 (where we enabled it on all platforms):
Android +260KB: supersize HTML diff
Fuchsia +98KB compressed: fuchsia-binary-size
The binary increase is distributed across files.

Our Efforts to Mitigate Size Increase:
We have already worked on reducing binary size in related areas. For instance, removing unnecessary templates and lambdas in our code reduced the Fuchsia compressed binary size by approximately one system page (8KB).
We also suspect that a lot of this will just be clang generated code passing the size parameter to the delete operator which will be spread out throughout the code base and difficult to reduce. For example, the angle disassemble results show an increase of approximately 6-8 instructions per delete operator call. This increase includes _LIBCPP_ASAN_VOLATILE_WRAPPER and __endian_factor, which to us are unexpected (especially since asan is not enabled).
Future Uses of Sized Deallocation:
Despite the size increase, enabling sized deallocation unlocks several capabilities (non-exhaustive list):
Improved ThreadCache Performance Experiments: We can run Finch performance experiments for ThreadCache by leveraging the size information. Note TCMalloc has found 1% fleet cycles savings and 3-5% for memory heavy applications.
Out-of-Bounds Write Detection: The known allocation size allows us to implement high performance detectors for out-of-bounds writes.
Questions:
For both Lexan and binary-size folks: Are there any further strategies, our internal implementation, or linker optimizations that would mitigate this size increase?
For Lexan folks: Is there any way to prevent _LIBCPP_ASAN_VOLATILE_WRAPPER and so on being added by clang in delete operator calls.
For binary-size folks: Considering the benefits of sized deallocation, is the observed binary size increase acceptable for Chrome on Android, and Fuchsia?
For binary-size folks: Also for other platforms less sensitive to binary size would this be okay to enable for the experiment?

--
You received this message because you are subscribed to the Google Groups "chrome-memory-tok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chrome-memory-...@google.com.
To view this discussion visit https://groups.google.com/a/google.com/d/msgid/chrome-memory-tok/CAHJiW_bkGrygRAYfeJuB0zDOWw1BJLxxC8w9M%3Drmp-eS%3DM5Ygw%40mail.gmail.com.
For more options, visit https://groups.google.com/a/google.com/d/optout.

Stephen Nusko

unread,

Nov 18, 2025, 11:41:03 PMNov 18

to binary-size, Stephen Nusko, Hans Wennborg, Ayumi Ono, Mikihito Matsuura

-@google.com mailing lists, apparently you can't post to them from your chromium account even if it is tied. So forking into two separate threads. Sorry for the noise.

To unsubscribe from this group and stop receiving emails from it, send an email to chrome-memory-tok+unsubscribe@google.com.

Andrew Grieve

unread,

Nov 19, 2025, 9:51:17 AMNov 19

to Stephen Nusko, binary-size, Hans Wennborg, Ayumi Ono, Mikihito Matsuura

The arm64 size result shows 4mb increase. Now, this size result has been known to be wildly off due to arm64's sensitivity to PGO. Probably the way to check is to land it and wait a couple of days and then compary canary build sizes.

Sounds like we should disable it when "optimize_for_size=true". This is true on arm32, but arm32 represents a dwindling number of devices, so it's not really a thing to care about.

To unsubscribe from this group and stop receiving emails from it, send an email to chrome-memory-...@google.com.

To view this discussion visit https://groups.google.com/a/google.com/d/msgid/chrome-memory-tok/CAHJiW_bkGrygRAYfeJuB0zDOWw1BJLxxC8w9M%3Drmp-eS%3DM5Ygw%40mail.gmail.com.
For more options, visit https://groups.google.com/a/google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "binary-size" group.
To unsubscribe from this group and stop receiving emails from it, send an email to binary-size...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/binary-size/158f2339-75ab-449c-9b45-cd0873bcd08cn%40chromium.org.

Stephen Nusko

unread,

Nov 19, 2025, 6:16:37 PMNov 19

to binary-size, Andrew Grieve, binary-size, Hans Wennborg, ayum...@google.com, Mikihito Matsuura, Stephen Nusko

Thanks Andrew,

`optimize_for_size` seems like a relevant gn arg indeed, do you know if Fuchsia would be opt-d out for that as well?

Wow didn't notice the 4MB for arm64... I'm glad that it is wildly off sometimes? Guess we can see based on Canary version as you suggest. Is there a doc or dashboard to check after we submit it?

No concerns launching this for all platforms that don't set `optimize_for_size=true`?

To unsubscribe from this group and stop receiving emails from it, send an email to chrome-memory-tok+unsubscribe@google.com.

To view this discussion visit https://groups.google.com/a/google.com/d/msgid/chrome-memory-tok/CAHJiW_bkGrygRAYfeJuB0zDOWw1BJLxxC8w9M%3Drmp-eS%3DM5Ygw%40mail.gmail.com.
For more options, visit https://groups.google.com/a/google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "binary-size" group.

To unsubscribe from this group and stop receiving emails from it, send an email to binary-size+unsubscribe@chromium.org.

Andrew Grieve

unread,

Nov 19, 2025, 6:43:45 PMNov 19

to Stephen Nusko, binary-size, Andrew Grieve, Hans Wennborg, ayum...@google.com, Mikihito Matsuura

I believe Fuschia does use optimize_for_size=true, so this would opt them out.

go/chrome-supersize is a quick way to check canary sizes. Use high-arm_65/TrichromeGoogle6432

To unsubscribe from this group and stop receiving emails from it, send an email to chrome-memory-...@google.com.

To view this discussion visit https://groups.google.com/a/google.com/d/msgid/chrome-memory-tok/CAHJiW_bkGrygRAYfeJuB0zDOWw1BJLxxC8w9M%3Drmp-eS%3DM5Ygw%40mail.gmail.com.
For more options, visit https://groups.google.com/a/google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "binary-size" group.

To unsubscribe from this group and stop receiving emails from it, send an email to binary-size...@chromium.org.

Reply all

Reply to author

Forward