WIP Experiment with different kind of allocator for backend.#824
WIP Experiment with different kind of allocator for backend.#824
Conversation
|
Tag me when you think it would be helpful for me to can kick the tires on this in an ad hoc fashion (or maybe I just hop on it anyway ;) ). |
It's a little premature yet. I just wanted to get a read on CI to see how bad it was, also pushed it to get my benchmarking infrastructure to take a look. The code is mostly me experimenting with CoPilot to see how well we can develop for snmalloc with it. There are good and bad bits. There are a few underlying concepts that will survive, but I will probably end up reimplementing a lot to be confident in the code. It has a habit of taking shortcuts way more than it should on a project like this. |
Add a backend range that delays returning memory to the next level. This reduces the pressure on the backend global allocator.
mjp41
force-pushed
the
generalisedbackend
branch
from
be719c9 to
88861f8
Compare
2 participants
The buddy allocator for large objects and chunks leads to good fragmentation behaviour, but can result in a lot of internal fragmentation as the blocks it returns can be twice the size requested. This PR makes the blocks have more sizeclasses using a DougLea/TLSF like consolidation strategy, but with some modification to handle the alignment requires for snmalloc.