Apply a blanket pass of including `new` for the placement new allocation
and namespacing the call to the global placement new allocator. This
should repair the Android ARMv7 builds.
Creating a task for an async let will attempt to allocate the task in the async let's preallocated space, and if there's any space left over then it will use the extra for the new tasks's allocator. However, StackAllocator requires the preallocated buffer to be large enough to hold a slab header, but the task creation code doesn't check for that. As a result, the task creation code can end up passing a buffer that's too small to hold the slab header. When asserts are enabled, this is caught by an assert. When asserts are not enabled, disaster strikes. We end up computing a negative number for the remaining slab capacity, which underflows to a large positive number, causing the slab to overflow the async let's preallocated space. This results in weird memory corruption.
SR-15996
rdar://90357994
This helps ensure that memory analysis tools don't get confused by leftover metadata pointers in reallocated memory that hasn't been initialized yet.
rdar://88494373
A slab capacity of 1000 bytes was overflowing the 1024 byte malloc bucket when adding in the slab header. Adjust it down to 984 bytes. Calculate this by subtracting the slab header size from 1024, plus a little slop for malloc stack logging, to ensure we don't overflow the bucket again.
rdar://87612288
We remove the existing `swift_reflection_iterateAsyncTaskAllocations` API that attempts to provide all necessary information about a tasks's allocations starting from the task. Instead, we split it into two pieces: `swift_reflection_asyncTaskSlabPointer` to get the first slab for a task, and `+swift_reflection_asyncTaskSlabAllocations` to get the allocations in a slab, and a pointer to the next slab.
We also add a dummy metadata pointer to the beginning of each slab. This allows tools to identify slab allocations on the heap without needing to locate every single async task object. They can then use `swift_reflection_asyncTaskSlabAllocations` on such allocations to find out about the contents.
rdar://82549631
On Windows, std::max_align_t is only 8-byte aligned, but Swift assumes 16-byte alignment. MaximumAlignment is our notion of the maximum alignment of a type, so use that instead.
We remove the existing `swift_reflection_iterateAsyncTaskAllocations` API that attempts to provide all necessary information about a tasks's allocations starting from the task. Instead, we split it into two pieces: `swift_reflection_asyncTaskSlabPointer` to get the first slab for a task, and `+swift_reflection_asyncTaskSlabAllocations` to get the allocations in a slab, and a pointer to the next slab.
We also add a dummy metadata pointer to the beginning of each slab. This allows tools to identify slab allocations on the heap without needing to locate every single async task object. They can then use `swift_reflection_asyncTaskSlabAllocations` on such allocations to find out about the contents.
rdar://82549631
Both swiftRuntime and swift_Concurrency had swift::fatalError
implementation, but it causes symbol conflict when -static-stdlib.
This patch renames one of the impl in swift_Concurrency to avoid
conflict.
Use the StackAllocator as task allocator.
TODO: we could pass an initial pre-allocated first slab to the allocator, which is allocated on the stack or with the parent task's allocator.
rdar://problem/71157018
A StackAllocator performs fast allocation and deallocation of memory by implementing a bump-pointer allocation strategy.
In contrast to a pure bump-pointer allocator, it's possible to free memory.
Allocations and deallocations must follow a strict stack discipline.
In general, slabs which become unused are _not_ freed, but reused for subsequent allocations.
The first slab can be placed into pre-allocated memory.
