3 ms·

When something would normally be freed, it calls the memory manager's version of free(), which zeroes the memory and adds it back into the appropriate available

When something would normally be freed, it calls the memory manager's version of free(), which zeroes the memory and adds it back into the appropriate available list.

LegionMammal978 2y ago
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.
- legohead 2y ago
  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.
  - LegionMammal978 2y ago
    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 https://github.com/microsoft/mimalloc
    - legohead 2y ago
      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.
      - thwarted 2y ago
        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.
        deleted 2y ago
        [deleted]
        legohead 2y ago
        There are always details within details. The overall idea is easily understandable. You are being pedantic.
        thwarted 2y ago
        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.
        shakna 2y ago
        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.
knorker 2y ago
You're just describing every allocator in the world, except many (most?) skip the zeroing part. libc already does that. What is it that yours is adding? I'd say 25 years ago you could write your own naive allocator, make just a couple of assumptions for your use case, and beat libc. But no more. One of the selling points of Java in the 90s was the compacting part. Because in the 90s fragmentation was a much bigger problem than it is today. Today the libc allocators have advanced by maybe tens of thousands of PhDs worth of theory and practice. Oh, and we have 64bit virtual address space, which helps with some (but not all) of the problems with memory fragmentation. See this post from Ian Lance Taylor about why Go didn't even bother with a compacting GC: https://groups.google.com/g/golang-nuts/c/KJiyv2mV2pU?pli=1 https://groups.google.com/g/golang-nuts/c/KJiyv2mV2pU?pli=1
- LegionMammal978 2y ago
  > Today the libc allocators have advanced by maybe tens of thousands of PhDs worth of theory and practice. Have they, though? Looking at the blame on glibc's malloc.c, the most substantial change in the last 10 years has been the addition of memory tagging. Apart from that, I mainly just see a bunch of small tweaks to the tcache, fastbins, etc., and the basic logic is broadly the same as it was 20 years ago. Similarly, the MallocInternals wiki page [0] appears mostly as it did in 2016, except for some more explanations of the tcache added in 2018. I can easily believe that lots of work has been done on malloc/free-style allocators, but from what I've seen of most libc allocators, they hardly stand at the forefront of this work. (Except for the ones that just vendor some standalone allocator library and keep it up to date. But that describes neither Windows nor Linux.) And of course, if you're writing your own allocator, you can relax some of the constraints, e.g., you can drop most of the multithreading support and not have to fool around with locks and shared arenas and whatnot. [0] https://sourceware.org/glibc/wiki/MallocInternals https://sourceware.org/glibc/wiki/MallocInternals
- legohead 2y ago
  > Today the libc allocators have advanced by maybe tens of thousands of PhDs worth of theory and practice. For fun I wrote up a very basic memory manager and benchmarked it against free/malloc. On my Mac (M3) the manager was 3x faster. On a random kubernetes pod (alpine) it was 33x faster. Performance increases as memory size goes up.

When something would normally be freed, it calls the memory manager's version of free(), which zeroes the memory and adds it back into the appropriate available list.

LegionMammal978 2y ago

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.

legohead 2y ago
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.
- LegionMammal978 2y ago
  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 https://github.com/microsoft/mimalloc
  - legohead 2y ago
    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.
    - thwarted 2y ago
      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.
      - deleted 2y ago
        [deleted]
      - legohead 2y ago
        There are always details within details. The overall idea is easily understandable. You are being pedantic.
        thwarted 2y ago
        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.
        shakna 2y ago
        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.

knorker 2y ago

You're just describing every allocator in the world, except many (most?) skip the zeroing part. libc already does that. What is it that yours is adding? I'd say 25 years ago you could write your own naive allocator, make just a couple of assumptions for your use case, and beat libc. But no more. One of the selling points of Java in the 90s was the compacting part. Because in the 90s fragmentation was a much bigger problem than it is today. Today the libc allocators have advanced by maybe tens of thousands of PhDs worth of theory and practice. Oh, and we have 64bit virtual address space, which helps with some (but not all) of the problems with memory fragmentation. See this post from Ian Lance Taylor about why Go didn't even bother with a compacting GC: https://groups.google.com/g/golang-nuts/c/KJiyv2mV2pU?pli=1 https://groups.google.com/g/golang-nuts/c/KJiyv2mV2pU?pli=1

LegionMammal978 2y ago
> Today the libc allocators have advanced by maybe tens of thousands of PhDs worth of theory and practice. Have they, though? Looking at the blame on glibc's malloc.c, the most substantial change in the last 10 years has been the addition of memory tagging. Apart from that, I mainly just see a bunch of small tweaks to the tcache, fastbins, etc., and the basic logic is broadly the same as it was 20 years ago. Similarly, the MallocInternals wiki page [0] appears mostly as it did in 2016, except for some more explanations of the tcache added in 2018. I can easily believe that lots of work has been done on malloc/free-style allocators, but from what I've seen of most libc allocators, they hardly stand at the forefront of this work. (Except for the ones that just vendor some standalone allocator library and keep it up to date. But that describes neither Windows nor Linux.) And of course, if you're writing your own allocator, you can relax some of the constraints, e.g., you can drop most of the multithreading support and not have to fool around with locks and shared arenas and whatnot. [0] https://sourceware.org/glibc/wiki/MallocInternals https://sourceware.org/glibc/wiki/MallocInternals
legohead 2y ago
> Today the libc allocators have advanced by maybe tens of thousands of PhDs worth of theory and practice. For fun I wrote up a very basic memory manager and benchmarked it against free/malloc. On my Mac (M3) the manager was 3x faster. On a random kubernetes pod (alpine) it was 33x faster. Performance increases as memory size goes up.