Lines Matching refs:to

2 This document describes how to verify the native memory allocator on Android.
3 This procedure should be followed when upgrading or moving to a new allocator.
4 A small minor upgrade might not need to run all of the benchmarks, however,
10 It is important to note that there are two modes for a native allocator
11 to run in on Android. The first is the normal allocator, the second is
12 called the svelte config, which is designed to run on memory constrained
14 add this line to the `BoardConfig.mk` for the given target:
26 a native allocator needs to implement.
29 These are functions that are used to implement a memory leak detector
34 call to an allocation function (malloc/free/etc). When a call
35 is made to `malloc_enable`, the paused threads should start running again.
39 to `malloc_disable`. This call will unpause any thread which is making
40 a call to an allocation function (malloc/free/etc) when `malloc_disable`
45 system. It is meant to be called after a call to `malloc_disable` to
52 to work efficiently.
55 When set to zero, `mallopt(M_DECAY_TIME, 0)`, it is expected that an
56 allocator will attempt to purge and release any unused memory back to the
57 kernel on free calls. This is important in Android to avoid consuming extra
60 When set to non-zero, `mallopt(M_DECAY_TIME, 1)`, an allocator can delay the
61 purge and release action. The amount of delay is up to the allocator
63 allocator was implemented to have a one second delay.
65 The drawback to this option is that most allocators do not have a separate
66 thread to handle the purge, so the decay is only handled when an
69 and no other allocation calls are made. The `M_PURGE` option is used to
73 made by default. The idea is that it allows application frees to run a
80 idea is that this can be called to purge memory that has not been
81 purged when `M_DECAY_TIME` is set to one. This is useful if you have a
83 application wants to purge that memory before waiting for the next connection.
86 These are the tests that should be run to verify an allocator is
87 working properly according to Android.
93 is passed to memalign.
100 The allocation tests are not meant to be complete, so it is expected
117 In addition to the bionic tests, there is also a CTS test that is designed
118 to verify that the addresses returned by malloc are sufficiently randomized
119 to help defeat potential security bugs.
125 If there are multiple devices connected to the system, use `-s <SERIAL>`
126 to specify a device.
129 There are multiple different ways to evaluate the performance of a native
144 These benchmarks are only used to verify the speed of the allocator and
145 ignore anything related to RSS and virtual address space consumed.
147 For all of these benchmark runs, it can be useful to add these two options:
153 and helps to get a number that can be compared to the new allocator.
159 Which will lock the benchmark to only run on core XX. This also avoids
160 any issue related to the code migrating from one core to another
162 benchmark moves from big to little or vice-versa, this can cause scores
163 to fluctuate in indeterminate ways.
165 For most runs, the best set of options to add is:
170 Choosing to run on the little core can tend to highlight any performance
174 These are the benchmarks to verify the allocation speed of a loop doing a
175 single allocation, touching every page in the allocation to make it resident
189 useful to look at these kinds of benchmarks to make sure that there are
190 no outliers, but these numbers should not be used to make a final decision.
201 Only the time it takes to do the allocations is recorded, the frees are not
207 This benchmark is designed to verify that there is no performance issue
208 related to having multiple allocations alive at the same time.
220 For these benchmarks, the last parameter is the total number of allocations to
223 The other variation of this benchmark is to always do forty allocations in
225 benchmark, only the time it takes to do the allocations is tracked, the
244 proximity of the current values is usually sufficient to consider making
252 This benchmark is designed to verify that the allocator will be performant
254 benchmark because these operations tend to do lots of malloc/realloc/free
255 calls, and they tend to be on the critical path of applications.
270 This benchmark only verifies that mallinfo is still close to the performance
278 Calls to mallinfo are used in ART so a new allocator is required to be
283 mallinfo benchmark, it's not necessary for this to be better than the previous
291 These calls are used to free unused memory pages back to the kernel.
295 address space consumed, speed of allocation. They are designed to
321 in all threads since it collapses all of the allocation operations to occur
324 so it is not possible to create a completely accurate replay.
329 To run these benchmarks, first copy the trace files to the target using
349 a good idea to look over the data to verify that no strange spikes are
352 The performance number is a measure of the time it takes to perform all of
355 it takes to make the pointer completely resident in memory is included.
357 The performance numbers for these runs tend to have a wide variability so
365 rather than delete them. When that happens, it can lead to allocation
366 failures and would cause the camera app to abort/crash. It is
367 important to verify that when running this trace using the 32 bit replay
384 If the native allocator creates a different name, then it necessary to
389 The `GetNativeInfo` function needs to be modified to include the name
392 In addition, in order for the frameworks code to keep track of the memory
393 of a process, any named maps must be added to the file:
411 traces and display data. It takes many minutes to complete these runs in
412 order to get as accurate a number as possible.