Daniel Micay
Daniel Micay
It is very difficult to do this well, so it requires a lot of thought.
Since slabs have a consistent size and predictable layout, it should be possible to do this quite well.
The large allocation header is 4x pointer size, so it is 16 bytes on 32-bit and 32 bytes on 64-bit. The headers and allocations end up aligned to the header...
A 4MiB chunk has room for 64 of the 64kiB slabs, but the first 64k is currently entirely lost due to the 8 byte chunk header. An alternative is for...
Storing the ID (address of `tcache` is fine) of the last thread to allocate from the arena would make it possible to force any other threads with that arena still...
This won't occur often in practice, so it's only worth doing if it's very low overhead.
One way to do this would be to add an additional chunk tier to the various LIFO free lists.
The current small size classes are the multiples of 16 in the range [16..512]. There are essentially no large size classes at all, as it simply rounds the size up...
Huge allocation sizes could be stored with page granularity in order to perform better purging.
It is currently `O(n_arenas * n_slots)` when it could be `O(n_slots)`. It's likely that the extra seeks over the list aren't a big deal, but it would be nice to...