This is an archive of the discontinued LLVM Phabricator instance.

[hwasan] Switch to 64 allocator with a dense size class map.
ClosedPublic

Authored by eugenis on Jan 2 2019, 5:26 PM.

Details

Summary

Replace the 32-bit allocator with a 64-bit one with a non-constant
base address, and reduce both the number of size classes and the maximum
size of per-thread caches.

As measured on [1], this reduces average weighted memory overhead
(MaxRSS) from 26% to 12% over stock android allocator. These numbers
include overhead from code instrumentation and hwasan shadow (i.e. not a
pure allocator benchmark).

This switch also enables release-to-OS functionality, which is not
implemented in the 32-bit allocator. I have not seen any effect from
that on the benchmark.

[1] https://android.googlesource.com/platform/system/extras/+/master/memory_replay/

Diff Detail

Event Timeline

eugenis created this revision.Jan 2 2019, 5:26 PM
vitalybuka accepted this revision.Jan 2 2019, 5:52 PM
This revision is now accepted and ready to land.Jan 2 2019, 5:52 PM
eugenis updated this revision to Diff 180158.Jan 3 2019, 3:17 PM

update tests

eugenis marked an inline comment as done.Jan 3 2019, 3:20 PM
eugenis added inline comments.
compiler-rt/test/hwasan/TestCases/heap-buffer-overflow.c
46 ↗(On Diff #180158)

@kcc btw these checks rely on the fact that this allocation is not the first in its size class. This assumption can be broken even w/o llvm/compiler-rt code changes - ex. by a change in libc startup code.

Not sure what to do about this. Maybe we should also describe the chunk that we think is the source of the overflow (that would be an improvement regardless) and test for that.

This revision was automatically updated to reflect the committed changes.
Herald added a subscriber: Restricted Project. · View Herald TranscriptJan 3 2019, 3:22 PM