Hacker News Reader

Comment by LegionMammal978 | Hacker News Reader

Isn't that just stacking your own allocator on top of the libc allocator, the same way the libc allocator is stacked on top of the OS's page mappings? It's often a sensible idea, of course, but I wouldn't describe it as "never freeing things", just substituting libc's malloc()/free() for your own. It's not like the libc allocator is doing something radically different from keeping lists of available and allocated memory.

View on HN

libc allocator is considered "slow" for the extra overhead it has. I'll just leave it at that as you can GPT the rest. I did some of my own testing back in the days I wrote C, and mine was significantly faster than malloc/free.

It's also a way, I suppose, to ensure your program has the memory it needs, depending on how you design it. Mine basically allocates all the expected memory I need at the start, while still being able to grab more if it needs. This was more of an issue back when you shared a server with lots of others.

Of course the libc allocator is slow, it's designed as a one-size-fits-all solution that's poorly tuned for most workloads and often doesn't get substantially updated for decades. By writing your own, you aren't avoiding an allocator, you're just avoiding the libc implementation of an allocator.

(In fact, most libcs let you just redefine the malloc(), free(), and realloc() functions to point to your own allocator instead of the default one, so you don't have to rewrite all the functions calling them. E.g., the mimalloc allocator [0] can be configured as a drop-in replacement for the libc allocator.)

[0] https://github.com/microsoft/mimalloc

I guess I'm confused at this chain of responses, then. As I'm doing what you are already suggesting.

Re-reading your comment, about the "not really freeing anything" -- I beg to differ, as when you do a real free(), it frees up memory for any program to use. As I already mentioned one of the benefits is once you have control of who can use that memory and aren't risking it not being available - disregarding some program that constantly grows in memory.

when you do a real free(), it frees up memory for any program to use

This is an extremely naive description of not only what the libc free() function does, but also of how memory management works in general.

There are always details within details. The overall idea is easily understandable. You are being pedantic.

Your description reveals a complete lack of understanding, and pointing out someone's lack of understanding is not being pedantic. Your choice of wording—"real free()" and "any program"—misrepresents the inherent complexity of implementing an allocator and does a disservice to both those less experienced and to the discussion in this thread.

You're assuming a platform. There are not a great number of guarantees when it comes to free:

The free subroutine deallocates a block of memory previously allocated by the malloc subsystem. Undefined results occur if the Pointer parameter is not an address that has previously been allocated by the malloc subsystem, or if the Pointer parameter has already been deallocated. If the Pointer parameter is NULL, no action occurs.

All that is guaranteed, is a deallocation. Not how and when that memory will become available again.

Your "more detailed" understanding will break, and will cause headaches, on platforms ypu're not used to.

> you have control of who can use that memory and aren't risking it not being available

overcommit would like to have a word

Reply on news.ycombinator.com