2012-12-04 15:54:41 +08:00
|
|
|
//===-- sanitizer_allocator.h -----------------------------------*- C++ -*-===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2012-12-04 15:54:41 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// Specialized memory allocator for ThreadSanitizer, MemorySanitizer, etc.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef SANITIZER_ALLOCATOR_H
|
|
|
|
#define SANITIZER_ALLOCATOR_H
|
|
|
|
|
|
|
|
#include "sanitizer_common.h"
|
2018-11-15 22:20:28 +08:00
|
|
|
#include "sanitizer_internal_defs.h"
|
|
|
|
#include "sanitizer_lfstack.h"
|
2012-12-04 15:54:41 +08:00
|
|
|
#include "sanitizer_libc.h"
|
|
|
|
#include "sanitizer_list.h"
|
2018-11-15 22:20:28 +08:00
|
|
|
#include "sanitizer_local_address_space_view.h"
|
2012-12-04 15:54:41 +08:00
|
|
|
#include "sanitizer_mutex.h"
|
2016-07-22 05:38:40 +08:00
|
|
|
#include "sanitizer_procmaps.h"
|
Introduce `AddressSpaceView` template parameter to `SizeClassAllocator32`, `FlatByteMap`, and `TwoLevelByteMap`.
Summary:
This is a follow up patch to r346956 for the `SizeClassAllocator32`
allocator.
This patch makes `AddressSpaceView` a template parameter both to the
`ByteMap` implementations (but makes `LocalAddressSpaceView` the
default), some `AP32` implementations and is used in `SizeClassAllocator32`.
The actual changes to `ByteMap` implementations and
`SizeClassAllocator32` are very simple. However the patch is large
because it requires changing all the `AP32` definitions, and users of
those definitions.
For ASan and LSan we make `AP32` and `ByteMap` templateds type that take
a single `AddressSpaceView` argument. This has been done because we will
instantiate the allocator with a type that isn't `LocalAddressSpaceView`
in the future patches. For the allocators used in the other sanitizers
(i.e. HWAsan, MSan, Scudo, and TSan) use of `LocalAddressSpaceView` is
hard coded because we do not intend to instantiate the allocators with
any other type.
In the cases where untemplated types have become templated on a single
`AddressSpaceView` parameter (e.g. `PrimaryAllocator`) their name has
been changed to have a `ASVT` suffix (Address Space View Type) to
indicate they are templated. The only exception to this are the `AP32`
types due to the desire to keep the type name as short as possible.
In order to check that template is instantiated in the correct a way a
`static_assert(...)` has been added that checks that the
`AddressSpaceView` type used by `Params::ByteMap::AddressSpaceView` matches
the `Params::AddressSpaceView`. This uses the new `sanitizer_type_traits.h`
header.
rdar://problem/45284065
Reviewers: kcc, dvyukov, vitalybuka, cryptoad, eugenis, kubamracek, george.karpenkov
Subscribers: mgorny, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D54904
llvm-svn: 349138
2018-12-14 17:03:18 +08:00
|
|
|
#include "sanitizer_type_traits.h"
|
2012-12-04 15:54:41 +08:00
|
|
|
|
|
|
|
namespace __sanitizer {
|
|
|
|
|
2018-04-14 03:21:27 +08:00
|
|
|
// Allows the tools to name their allocations appropriately.
|
|
|
|
extern const char *PrimaryAllocatorName;
|
|
|
|
extern const char *SecondaryAllocatorName;
|
|
|
|
|
2017-06-21 05:23:02 +08:00
|
|
|
// Since flags are immutable and allocator behavior can be changed at runtime
|
|
|
|
// (unit tests or ASan on Android are some examples), allocator_may_return_null
|
|
|
|
// flag value is cached here and can be altered later.
|
|
|
|
bool AllocatorMayReturnNull();
|
|
|
|
void SetAllocatorMayReturnNull(bool may_return_null);
|
2016-09-30 07:00:54 +08:00
|
|
|
|
2017-06-21 05:23:02 +08:00
|
|
|
// Returns true if allocator detected OOM condition. Can be used to avoid memory
|
2018-06-21 01:10:33 +08:00
|
|
|
// hungry operations.
|
2017-06-21 05:23:02 +08:00
|
|
|
bool IsAllocatorOutOfMemory();
|
2018-06-21 01:10:33 +08:00
|
|
|
// Should be called by a particular allocator when OOM is detected.
|
2018-03-29 02:22:40 +08:00
|
|
|
void SetAllocatorOutOfMemory();
|
2016-09-30 07:00:54 +08:00
|
|
|
|
2018-06-21 01:10:33 +08:00
|
|
|
void PrintHintAllocatorCannotReturnNull();
|
|
|
|
|
2012-12-12 22:32:18 +08:00
|
|
|
// Allocators call these callbacks on mmap/munmap.
|
|
|
|
struct NoOpMapUnmapCallback {
|
|
|
|
void OnMap(uptr p, uptr size) const { }
|
|
|
|
void OnUnmap(uptr p, uptr size) const { }
|
|
|
|
};
|
|
|
|
|
2013-06-24 16:34:50 +08:00
|
|
|
// Callback type for iterating over chunks.
|
|
|
|
typedef void (*ForEachChunkCallback)(uptr chunk, void *arg);
|
|
|
|
|
2020-09-17 22:04:50 +08:00
|
|
|
inline u32 Rand(u32 *state) { // ANSI C linear congruential PRNG.
|
[sanitizer] Random shuffling of chunks for the 32-bit Primary Allocator
Summary:
The 64-bit primary has had random shuffling of chunks for a while, this
implements it for the 32-bit primary. Scudo is currently the only user of
`kRandomShuffleChunks`.
This change consists of a few modifications:
- move the random shuffling functions out of the 64-bit primary to
`sanitizer_common.h`. Alternatively I could move them to
`sanitizer_allocator.h` as they are only used in the allocator, I don't feel
strongly either way;
- small change in the 64-bit primary to make the `rand_state` initialization
`UNLIKELY`;
- addition of a `rand_state` in the 32-bit primary's `SizeClassInfo` and
shuffling of chunks when populating the free list.
- enabling the `random_shuffle.cpp` test on platforms using the 32-bit primary
for Scudo.
Some comments on why the shuffling is done that way. Initially I just
implemented a `Shuffle` function in the `TransferBatch` which was simpler but I
came to realize this wasn't good enough: for chunks of 10000 bytes for example,
with a `CompactSizeClassMap`, a batch holds only 1 chunk, meaning shuffling the
batch has no effect, while a region is usually 1MB, eg: 104 chunks of that size.
So I decided to "stage" the newly gathered chunks in a temporary array that
would be shuffled prior to placing the chunks in batches.
The result is looping twice through n_chunks even if shuffling is not enabled,
but I didn't notice any significant significant performance impact.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D39244
llvm-svn: 316596
2017-10-26 01:24:56 +08:00
|
|
|
return (*state = *state * 1103515245 + 12345) >> 16;
|
|
|
|
}
|
|
|
|
|
2020-09-17 22:04:50 +08:00
|
|
|
inline u32 RandN(u32 *state, u32 n) { return Rand(state) % n; } // [0, n)
|
[sanitizer] Random shuffling of chunks for the 32-bit Primary Allocator
Summary:
The 64-bit primary has had random shuffling of chunks for a while, this
implements it for the 32-bit primary. Scudo is currently the only user of
`kRandomShuffleChunks`.
This change consists of a few modifications:
- move the random shuffling functions out of the 64-bit primary to
`sanitizer_common.h`. Alternatively I could move them to
`sanitizer_allocator.h` as they are only used in the allocator, I don't feel
strongly either way;
- small change in the 64-bit primary to make the `rand_state` initialization
`UNLIKELY`;
- addition of a `rand_state` in the 32-bit primary's `SizeClassInfo` and
shuffling of chunks when populating the free list.
- enabling the `random_shuffle.cpp` test on platforms using the 32-bit primary
for Scudo.
Some comments on why the shuffling is done that way. Initially I just
implemented a `Shuffle` function in the `TransferBatch` which was simpler but I
came to realize this wasn't good enough: for chunks of 10000 bytes for example,
with a `CompactSizeClassMap`, a batch holds only 1 chunk, meaning shuffling the
batch has no effect, while a region is usually 1MB, eg: 104 chunks of that size.
So I decided to "stage" the newly gathered chunks in a temporary array that
would be shuffled prior to placing the chunks in batches.
The result is looping twice through n_chunks even if shuffling is not enabled,
but I didn't notice any significant significant performance impact.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D39244
llvm-svn: 316596
2017-10-26 01:24:56 +08:00
|
|
|
|
|
|
|
template<typename T>
|
2020-09-17 22:04:50 +08:00
|
|
|
inline void RandomShuffle(T *a, u32 n, u32 *rand_state) {
|
[sanitizer] Random shuffling of chunks for the 32-bit Primary Allocator
Summary:
The 64-bit primary has had random shuffling of chunks for a while, this
implements it for the 32-bit primary. Scudo is currently the only user of
`kRandomShuffleChunks`.
This change consists of a few modifications:
- move the random shuffling functions out of the 64-bit primary to
`sanitizer_common.h`. Alternatively I could move them to
`sanitizer_allocator.h` as they are only used in the allocator, I don't feel
strongly either way;
- small change in the 64-bit primary to make the `rand_state` initialization
`UNLIKELY`;
- addition of a `rand_state` in the 32-bit primary's `SizeClassInfo` and
shuffling of chunks when populating the free list.
- enabling the `random_shuffle.cpp` test on platforms using the 32-bit primary
for Scudo.
Some comments on why the shuffling is done that way. Initially I just
implemented a `Shuffle` function in the `TransferBatch` which was simpler but I
came to realize this wasn't good enough: for chunks of 10000 bytes for example,
with a `CompactSizeClassMap`, a batch holds only 1 chunk, meaning shuffling the
batch has no effect, while a region is usually 1MB, eg: 104 chunks of that size.
So I decided to "stage" the newly gathered chunks in a temporary array that
would be shuffled prior to placing the chunks in batches.
The result is looping twice through n_chunks even if shuffling is not enabled,
but I didn't notice any significant significant performance impact.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D39244
llvm-svn: 316596
2017-10-26 01:24:56 +08:00
|
|
|
if (n <= 1) return;
|
2018-05-16 23:13:26 +08:00
|
|
|
u32 state = *rand_state;
|
[sanitizer] Random shuffling of chunks for the 32-bit Primary Allocator
Summary:
The 64-bit primary has had random shuffling of chunks for a while, this
implements it for the 32-bit primary. Scudo is currently the only user of
`kRandomShuffleChunks`.
This change consists of a few modifications:
- move the random shuffling functions out of the 64-bit primary to
`sanitizer_common.h`. Alternatively I could move them to
`sanitizer_allocator.h` as they are only used in the allocator, I don't feel
strongly either way;
- small change in the 64-bit primary to make the `rand_state` initialization
`UNLIKELY`;
- addition of a `rand_state` in the 32-bit primary's `SizeClassInfo` and
shuffling of chunks when populating the free list.
- enabling the `random_shuffle.cpp` test on platforms using the 32-bit primary
for Scudo.
Some comments on why the shuffling is done that way. Initially I just
implemented a `Shuffle` function in the `TransferBatch` which was simpler but I
came to realize this wasn't good enough: for chunks of 10000 bytes for example,
with a `CompactSizeClassMap`, a batch holds only 1 chunk, meaning shuffling the
batch has no effect, while a region is usually 1MB, eg: 104 chunks of that size.
So I decided to "stage" the newly gathered chunks in a temporary array that
would be shuffled prior to placing the chunks in batches.
The result is looping twice through n_chunks even if shuffling is not enabled,
but I didn't notice any significant significant performance impact.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D39244
llvm-svn: 316596
2017-10-26 01:24:56 +08:00
|
|
|
for (u32 i = n - 1; i > 0; i--)
|
2018-05-16 23:13:26 +08:00
|
|
|
Swap(a[i], a[RandN(&state, i + 1)]);
|
|
|
|
*rand_state = state;
|
[sanitizer] Random shuffling of chunks for the 32-bit Primary Allocator
Summary:
The 64-bit primary has had random shuffling of chunks for a while, this
implements it for the 32-bit primary. Scudo is currently the only user of
`kRandomShuffleChunks`.
This change consists of a few modifications:
- move the random shuffling functions out of the 64-bit primary to
`sanitizer_common.h`. Alternatively I could move them to
`sanitizer_allocator.h` as they are only used in the allocator, I don't feel
strongly either way;
- small change in the 64-bit primary to make the `rand_state` initialization
`UNLIKELY`;
- addition of a `rand_state` in the 32-bit primary's `SizeClassInfo` and
shuffling of chunks when populating the free list.
- enabling the `random_shuffle.cpp` test on platforms using the 32-bit primary
for Scudo.
Some comments on why the shuffling is done that way. Initially I just
implemented a `Shuffle` function in the `TransferBatch` which was simpler but I
came to realize this wasn't good enough: for chunks of 10000 bytes for example,
with a `CompactSizeClassMap`, a batch holds only 1 chunk, meaning shuffling the
batch has no effect, while a region is usually 1MB, eg: 104 chunks of that size.
So I decided to "stage" the newly gathered chunks in a temporary array that
would be shuffled prior to placing the chunks in batches.
The result is looping twice through n_chunks even if shuffling is not enabled,
but I didn't notice any significant significant performance impact.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: srhines, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D39244
llvm-svn: 316596
2017-10-26 01:24:56 +08:00
|
|
|
}
|
|
|
|
|
2016-07-21 06:06:41 +08:00
|
|
|
#include "sanitizer_allocator_size_class_map.h"
|
|
|
|
#include "sanitizer_allocator_stats.h"
|
|
|
|
#include "sanitizer_allocator_primary64.h"
|
|
|
|
#include "sanitizer_allocator_bytemap.h"
|
|
|
|
#include "sanitizer_allocator_primary32.h"
|
|
|
|
#include "sanitizer_allocator_local_cache.h"
|
|
|
|
#include "sanitizer_allocator_secondary.h"
|
|
|
|
#include "sanitizer_allocator_combined.h"
|
|
|
|
|
2015-09-30 02:23:36 +08:00
|
|
|
} // namespace __sanitizer
|
2012-12-04 15:54:41 +08:00
|
|
|
|
2015-09-30 02:23:36 +08:00
|
|
|
#endif // SANITIZER_ALLOCATOR_H
|