Live data from Hacker News

Writing a Memory Allocator (2019)

dmitrysoshnikov.com

41–44 of 44 posts

Re: Writing a Memory Allocator (2019)

#41

I built a memory allocator for testing not too long ago that only allocated but no-op'd deallocate(using the C++ Allocator interface). It was quite amazing that it resulted in a 25-50% performance boost in many cases I was testing. It's not for real code as you only get destruction but not deallocation. It let me pull that part out of the tests to get a better view of the performance

this is why composable allocators are fantastic. You can request a dynamic memory slate for a given context, then allocate as you wish, no-op delete, when you're done with the context, you delete all of them in one go.

Re: Writing a Memory Allocator (2019)

#42
I am curious, is it possible to implement a headerless allocator? Basically keep an index of free blocks and an index of used blocks using a B-tree or a skip list, and allocate and free them by simply moving from one index to the other. Presumably this would make it more cache friendly.

Toying with allocators is one of my favorite programming pastimes for some reason.

Re: Writing a Memory Allocator (2019)

#43
post #33
post #26

Earlier quoted context omitted.

Can you explain what you mean by mmap is how memory is obtained nowadays?

mmap is not only to map a file content into a process address space, it can also be used to request memory from the OS using the MAP_ANONYMOUS flag. Early on a malloc-like allocator would use brk/sbrk to get a chunk of "raw" memory, and manage this for the user providing access using malloc/free. Nowadays the same "raw" memory can be obtained using an anonymous map. A raw pool, when unused, can be returned to the OS…

sbrk is emulated via mmap today on MacOS and others, this is an abstraction (for bump allocation), not just a function

you may implement custom sbrk via mmap easily

Post reply on HN