Lines Matching refs:is

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
18 The `BoardConfig.mk` file is usually found in the directory
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
45 system. It is meant to be called after a call to `malloc_disable` to
46 prevent further allocations while this call is being executed. To
47 see what is expected for this function, the best description is the
55 When set to zero, `mallopt(M_DECAY_TIME, 0)`, it is expected that an
57 kernel on free calls. This is important in Android to avoid consuming extra
61 purge and release action. The amount of delay is up to the allocator
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
68 RSS is slightly higher when the server is waiting for the next connection
69 and no other allocation calls are made. The `M_PURGE` option is used to
72 For all applications on Android, the call `mallopt(M_DECAY_TIME, 1)` is
73 made by default. The idea is that it allows application frees to run a
78 any unused memory immediately. The argument for this call is ignored. If
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
86 These are the tests that should be run to verify an allocator is
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
130 allocator on Android. One is allocation speed in various different scenarios,
131 another is total RSS taken by the allocator.
133 The last is virtual address space consumed in 32 bit applications. There is
136 address space is consumed. For 64 bit executables, this can be ignored.
155 In addition, there is another option:
165 For most runs, the best set of options to add is:
169 On most phones with a big-little cpu, the third core is the little core.
188 The last value in the output is the size of the allocation in bytes. It is
192 single thread numbers from trace data is a better representative of
201 Only the time it takes to do the allocations is recorded, the frees are not
203 had issues with this size. It is possible other sizes might show different
205 not be used as absolutes for determining if an allocator is worth using.
207 This benchmark is designed to verify that there is no performance issue
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
226 frees are not counted. Forty allocations is an arbitrary number that could
240 For these benchmarks, the last parameter in the output is the size of the
244 proximity of the current values is usually sufficient to consider making
249 This benchmark is a trace of the allocations performed when running
252 This benchmark is designed to verify that the allocator will be performant
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
319 on a thread as if it was rerunning the real trace. The only issue is that
320 this is a worst case scenario for allocations happening at the same time
324 so it is not possible to create a completely accurate replay.
342 Where XXX.zip is the name of a zipped trace file. The `memory_replay`
348 For the most part, the intermediate data can be ignored, but it is always
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.
362 When evaluating an allocator, one of the most important traces is the
366 failures and would cause the camera app to abort/crash. It is
368 executable, the virtual address space consumed is not much larger than the
371 There is no specific benchmark for memory fragmentation, instead, the RSS
373 is fragmenting badly will show an increase in RSS. The best trace for
374 tracking fragmentation is system\_server.txt which is an extremely long
379 NOTE: When a native allocator calls mmap, it is expected that the allocator
400 This is a benchmark that treats the trace data as if all allocations
401 occurred in a single thread. This is the scenario that could