using malloc on custom memory allocator

[alitokur]

I just wanted to start by saying how much I appreciate the code you shared. It's been really helpful for someone like me who's curious about how memory allocation works.

As I was going through the code, I came across something interesting about arena allocators. I have a question that I've been wondering about, and I'm hoping you could help me understand it better.

In the arena allocator concept, I noticed that a big chunk of memory is allocated using "malloc" just once. Then, whenever more memory is needed, it's taken from this big chunk. This sounds like a smart way to avoid calling "malloc" many times, which is great for making things faster. But I got a bit stuck on a thought.

Isn't "malloc" already a memory allocator? It's a tool that uses its own special methods to get memory from the computer. So, when we use an arena allocator, are we sort of using "malloc" to make a special area for memory, and then we use the arena thing to get memory from that special area? This feels like using one memory tool (the arena thing) on top of another one we already had (the "malloc" thing). Using sbrk() might be another option?

I'm really interested in your take on this. Could you share your thoughts?

Thanks a bunch!

[mtrebi]

Hey,

Thank you for the kind words. I did this project a while ago and I can't believe people still find it useful.

You're right about everything you said. The arena or other custom allocators work by doing fewer malloc calls (usually on startup) and then managing the memory by themselves, instead of doing a malloc every time. It is effectively one memory tool on top of another.

Why we need an additional memory tool on top of malloc? Malloc performance is not terrible but it's a bit inconsistent and sometimes it can be really slow. Malloc usually takes the memory from the user/app space if there's some available but if there's not, it needs to do system/OS call to request for more memory. This operation requires to switch the context (from user to OS and the back again to user). This is absurdly slow. The point of doing fewer mallocs, specially at start up is to reduce these slow operations, we'll do them once and that's it. After that, our allocations will be super fast.

Why the OS doesn't do that for us? Well, because it doesn't know how much memory our program will use but we do, or at least we have a rough idea. Having this information, allows us to allocate the memory in advance for our custom allocator and save syscalls.

I am no expert in this matter, so I suggest you to research about this interesting topic,

All the best,
Mariano.