[all-commits] [llvm/llvm-project] 041547: scudo: Table driven size classes for Android alloc...

[pcc via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 041547eb4eb0fcb2155af7537aaed7f601ea6343
      https://github.com/llvm/llvm-project/commit/041547eb4eb0fcb2155af7537aaed7f601ea6343
  Author: Peter Collingbourne <peter at pcc.me.uk>
  Date:   2020-02-10 (Mon, 10 Feb 2020)

  Changed paths:
    M compiler-rt/lib/scudo/standalone/size_class_map.h
    M compiler-rt/lib/scudo/standalone/tests/combined_test.cpp
    M compiler-rt/lib/scudo/standalone/tests/size_class_map_test.cpp
    A compiler-rt/lib/scudo/standalone/tools/compute_size_class_config.cpp

  Log Message:
  -----------
  scudo: Table driven size classes for Android allocator.

Add an optional table lookup after the existing logarithm computation
for MidSize < Size <= MaxSize during size -> class lookups. The lookup is
O(1) due to indexing a precomputed (via constexpr) table based on a size
table. Switch to this approach for the Android size class maps.

Other approaches considered:
- Binary search was found to have an unacceptable (~30%) performance cost.
- An approach using NEON instructions (see older version of D73824) was found
  to be slightly slower than this approach on newer SoCs but significantly
  slower on older ones.

By selecting the values in the size tables to minimize wastage (for example,
by passing the malloc_info output of a target program to the included
compute_size_class_config program), we can increase the density of allocations
at a small (~0.5% on bionic malloc_sql_trace as measured using an identity
table) performance cost.

Reduces RSS on specific Android processes as follows (KB):

                             Before  After
zygote (median of 50 runs)    26836  26792 (-0.2%)
zygote64 (median of 50 runs)  30384  30076 (-1.0%)
dex2oat (median of 3 runs)   375792 372952 (-0.8%)

I also measured the amount of whole-system idle dirty heap on Android by
rebooting the system and then running the following script repeatedly until
the results were stable:

for i in $(seq 1 50); do grep -A5 scudo: /proc/*/smaps | grep Pss: | cut -d: -f2 | awk '{s+=$1} END {print s}' ; sleep 1; done

I did this 3 times both before and after this change and the results were:

Before: 365650, 356795, 372663
After:  344521, 356328, 342589

These results are noisy so it is hard to make a definite conclusion, but
there does appear to be a significant effect.

On other platforms, increase the sizes of all size classes by a fixed offset
equal to the size of the allocation header. This has also been found to improve
density, since it is likely for allocation sizes to be a power of 2, which
would otherwise waste space by pushing the allocation into the next size class.

Differential Revision: https://reviews.llvm.org/D73824