Re: Binary Size Impact of Enabling Sized Deallocation in PartitionAlloc
Stephen Nusko
+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
To unsubscribe from this group and stop receiving emails from it, send an email to chrome-memory-tok+unsubscribe@google.com.
Andrew Grieve
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
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
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.