Matthew Parkinson de8ef3efc7 Cleaner implementation of signed pointers. (#347)
* Cleaner implementation of signed pointers.

This encodes a back pointer in each node.  The back pointer is stored
in an encoded form so that it is hard to corrupt and trick the allocator
into following incorrect pointers.

This changes the encoding from previously being a Feistel network on
the next pointer that was using the prev as part of the key, to now
effectively using a doubly linked queue, where the back pointers are
scrambled, so it is hard to forge them.

This has the positive effects of
 - Not needing to store previous while building the list, as the append
   nows, curr and next at the point of writing into next, and does not
   need an additional previous.
 - The encoding is not affecting the actual next value, so more
   instructions can be executed in parallel by the CPU.

Future extensions, store a changing key in the FreeListBuilder so it
becomes harder to try to forge the previous token.

This approach can also be applied to the remote list, and will in a
subsequent PR.  This enables the idea to be tested.

* Remove unused header.

* Apply suggestions from code review

Co-authored-by: Nathaniel Wesley Filardo <VP331RHQ115POU58JFRLKB7OPA0L18E3@cmx.ietfng.org>

Co-authored-by: Nathaniel Wesley Filardo <VP331RHQ115POU58JFRLKB7OPA0L18E3@cmx.ietfng.org>
2021-07-15 18:31:28 +01:00
2021-07-12 15:53:36 +01:00
2021-07-12 15:53:36 +01:00
2020-02-06 09:09:32 +00:00
2019-04-30 09:46:10 +01:00
2019-05-21 09:47:23 +01:00
2019-01-09 06:05:57 -08:00
2020-02-28 09:03:41 +00:00
2019-05-23 15:13:47 +01:00

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.

Build Status

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.

Description
No description provided
Readme MIT 6.1 MiB
Languages
C++ 95.4%
CMake 3.6%
C 0.5%
Starlark 0.4%
Dockerfile 0.1%