65ee6b2a2f
MetaCommon is now gone. The back end must provide a SlabMetadata, which must be a subtype of MetaSlab (i.e. MetaSlab or a subclass of MetaSlab). It may add additional state here. The MetaEntry is now templated on the concrete subclass of MetaSlab that the back-end uses. The MetaEntry still stores this as a `uintptr_t` to allow easier toggling of the boundary bit but the interfaces are all in terms of stable types now. Also some tidying of names (SharedStateHandle is now called Backend). In a follow-on PR, we can then remove the chunk field from the BackendMetadata in the non-CHERI back end and allow back ends that don't require extra state to use MetaSlab directly. Other cleanups: - Remove backend/metatypes, define the types that the front end expects in mem/metaslab. The back end may extend them but these types define part of the contract between the front and back ends. - Remove FrontendMetaEntry and fold its methods into MetaEntry. - For example purposes, the default back end now extends MetaEntry. This also ensures that nothing in the front end depends on the specific type of MetaEntry. - Some things now have more sensible names. The meta entry now operates in one of three modes: - When owned by the front end, it stores a pointer to a remote, a pointer to some MetaSlab subclass, and a sizeclass. - When owned by the back end, it stores two back-end defined values that must fit in the bits of `uintptr_t` that are not reserved for the MetaEntry itself. - When not owned by either, it can be queried as if owned by the front end. The red-black tree has been refactored to allow the holder to be a wrapper type, removing all of the Holder* and Holder& uses and treating it uniformly as a value type that can be used to access the contents. The chunk field is fone from the slab medatada. This will need to be added back in the CHERI back ends, but it's a back-end policy. The back end can choose to use it or not, depending on whether it can safely convert between an Alloc-bounded pointer and a Chunk-bounded pointer. The term 'metaslab' originated in snmalloc 1 to mean a slab of slabs. In the snmalloc2 branch it was repurposed to mean metadata about a slab. To make this clearer, all uses of metaslab are now gone and have been renamed to slab metadata. The frontend metadata classes are all prefixed Frontend and some extra invariants are checked with `static_assert`.
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.
Comprehensive details about snmalloc's design can be found in the accompanying paper, and differences between the paper and the current implementation are described here. Since writing the paper, the performance of snmalloc has improved considerably.
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.