5f7baef755
* Factor out explicit Config type Instead of using snmalloc::Alloc::Config, expose snmalloc::Config, which is then used to derive the allocator type. * Move globalalloc to front end. * Remove unneed template parameter from global snmalloc functions. * Remove SNMALLOC_PASS_THROUGH VeronaRT now has an abstraction layer which can easily replace the allocator. Having such a complex integration still in snmalloc does not make sense. * Take some global functions off of local alloc. * Drop comparison overloads on atomic Capptr. Performing a comparison on two atomic ptr is a complex operation, and should not be implicit. The memory model order and such things needs to be considered by the caller. * Remove function_ref and use templates The implementation prefers to use templates over the function_ref. This now only exists in the Pal for a currently unused feature. * Removing function_ref reduces stl needs. * Remove use of __is_convertible to support older g++ * Inline function that is only used once. * Remove unused function * Restrict ThreadAlloc usage to globalalloc This commit introduces various inline functions on snmalloc:: that perform allocation/deallocation using the thread local allocator. They remove all usage from a particular test. * Move cheri checks to own file. * Refactor is_owned checks. * Move alloc_size and check_size to globalalloc. * Minor simplification of dealloc path * Fix up is_owned to take a config * Improve usage of scoped allocator. * Handle Config_ in globalalloc.
snmalloc
snmalloc is a high-performance allocator.
snmalloc can be used directly in a project as a header-only C++ library,
it can be LD_PRELOADed on Elf platforms (e.g. Linux, BSD),
and there is a crate to use it from Rust.
Its key design features are:
- Memory that is freed by the same thread that allocated it does not require any synchronising operations.
- Freeing memory in a different thread to initially allocated it, does not take any locks and instead uses a novel message passing scheme to return the memory to the original allocator, where it is recycled. This enables 1000s of remote deallocations to be performed with only a single atomic operation enabling great scaling with core count.
- The allocator uses large ranges of pages to reduce the amount of meta-data required.
- The fast paths are highly optimised with just two branches on the fast path for malloc (On Linux compiled with Clang).
- The platform dependencies are abstracted away to enable porting to other platforms.
snmalloc's design is particular well suited to the following two difficult scenarios that can be problematic for other allocators:
- Allocations on one thread are freed by a different thread
- Deallocations occur in large batches
Both of these can cause massive reductions in performance of other allocators, but do not for snmalloc.
The implementation of snmalloc has evolved significantly since the initial paper. The mechanism for returning memory to remote threads has remained, but most of the meta-data layout has changed. We recommend you read docs/security to find out about the current design, and if you want to dive into the code docs/AddressSpace.md provides a good overview of the allocation and deallocation paths.
Hardening
There is a hardened version of snmalloc, it contains
- Randomisation of the allocations' relative locations,
- Most meta-data is stored separately from allocations, and is protected with guard pages,
- All in-band meta-data is protected with a novel encoding that can detect corruption, and
- Provides a
memcpythat automatically checks the bounds relative to the underlying malloc.
A more comprehensive write up is in docs/security.
Further documentation
Contributing
This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.
When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.