Allocation is always cheap, also with manual memory management. It's reclaiming/freeing memory which is the tricky part ;)

Best approach is still to minimize dynamic allocation as much as possible. One can often get surprisingly far with an entirely static memory layout that's defined upfront at application start.

In support of flohofwoe's point: good implementations of malloc will, on the common path, just bump a pointer without synchronization. The allocation path of good manual allocator implementations and garbage collectors will probably look similar.

> In support of flohofwoe's point: good implementations of malloc will, on the common path, just bump a pointer without synchronization.

How does this work when the heap address space becomes fragmented, with randomly distributed available space and objects that are still live? You can't just bump when the next piece of memory may still be in use, and when you're not able to move memory.

That's the uncommon path.

Yes, exactly. And! It exists in garbage collectors, too.

Why would you ever encounter a fragmented Eden in a garbage collector?

I wasn't thinking of that case in particular, but that there are other instance in a garbage collector where you will not just be able to bump a pointer: you need to request more memory from the OS, or you need to start a collection phase before satisfying a memory request.

Very good GCs can be faster compared to common system allocators while minimizing the STW moment, but you cannot beat using a proper allocator for your needs.

> but you cannot beat using a proper allocator for your needs

How do you know this to be true?

And why isn't a GC a 'proper' allocator?