4 ms·

> Last but not least, chibicc allocates memory using calloc but never calls free. Allocated heap memory is not freed until the process exits. I'm sure that this

> Last but not least, chibicc allocates memory using calloc but never calls free. Allocated heap memory is not freed until the process exits. I'm sure that this memory management policy (or lack thereof) looks very odd, but it makes sense for short-lived programs such as compilers. I’ve thought about this – why isn’t this a more common thing to do for short-lived programs such as cli programs? Or is it common – could anyone give some examples of well-used programs that do this? The reasons to not do it that I could think of is: 1. “It’s just bad practice” 2. You may suddenly find yourself having written some kind of malloc bomb, more easily than you think

teo_zero 4y ago
I always use this technique. It make no sense to free() all the memory just before the exit(). But the prerequisite isn't whether the program is short-lived, but rather that the memory usage pattern is "alloc often, free at the end".
- simonkagedal 4y ago
  With ”short-lived”, I rather meant something like: ”does one job and then exits”, as opposed to something more dynamic – of course, that it takes a long or short time to execute isn’t by itself relevant.
rui314 4y ago
It caused a flame war, so #1 factor is not negligible.
- simonkagedal 4y ago
  Haha, I bet! If you happen to have the link, I’d be curious! (And let me take the opportunity to give kudos, this looks super cool!)
liuliu 4y ago
If you know it will always be short lived, that's fine. But even compilers are not strictly short lived nowadays. Both Swift and Rust (I think) maintains a daemon process to assist incremental compilation.
- simonkagedal 4y ago
  Good point!
- SpaghettiCthulu 4y ago
  Rust doesn't use a daemon process, it just caches on disk.
_flux 4y ago
It can be quite painful to add them afterwards and while the program might now be shortlived, this might not hold true in the future. And just maybe if one doesn't want to deal with manual memory management, then pick a tool/language that doesn't require it? Maybe a practical alternative to this—that would still reap the performance benefits—would be to have an allocator that postpones frees until certain time (or e.g. number of bytes allocated) has been passed since the start of the program, and after that point works like normal alloc/free. Actually this is not far from how garbage collecting languages work..
- SpaghettiCthulu 4y ago
  Arena allocators are pretty common for that.
leni536 4y ago
As for C++, memory is not the only resource you can leak. When you leak, then you leak objects with it, and they can hold on to other resources that you might want to clean deterministically. Having said that nothing stops you from replacing the global allocation functions, so that deallocation is noop. But your program, and especially libraries should still match up malloc/free, new/delete and allocate/deallocate. Also your default malloc probably does a bunch of bookkeeping that is eventually only used by free. Once you decide that you won't call free or use a noop free, then there are potentially better candidate implementations for malloc as well.
Kukumber 4y ago
because computers are not "single task", and you cli is not the only thing that's running also memory cost money, no big deal for your machine, but scale this to a fleet of thousands of machines and it start to cost big money then people wonder why their burnrate is indecently high
- unwind 4y ago
  Huh? Modern OSes will of course free the memory (as well as any other resources) when the process exits. If you know your program has limited runtime you can treat standard heap allocation functions like an over-engineered arena allocator. :)
- simonkagedal 4y ago
  I did not mean the cli itself (such as bash), but small programs it executes (such as ls). Also not arguing for the practice as a general strategy, but feels like it could have a place!
astrobe_ 4y ago
In my experience it is about code reuse and/or maintainability - what if this code becomes a library and is integrated as part of a long-lived program? It would be risky a posteriori to retrofit a proper memory management. And perhaps, there's something about programming habits. We hear often enough about C having not enough safeties, and one way to mitigate the issue is having "safe" habits. Kind of like how you activate your blinker when you turn even when there's nobody around; if you don't, you might forget to activate it when it matters.
- simonkagedal 4y ago
  Yep, I was thinking that there could be a good and bad form of my first argument, and this sounds like the former!
- jstimpfle 4y ago
  It's considerably more work to get a piece of software in shape for use as a library. Matching all callocs with frees is not a huge amount of work, but if you know that there's no requirement to do it, you might as well save the typing. Kind of like I admit I often don't active the blinker when nobody is around, because it means a little inconvenience and it requires you to get one hand off the steering wheel, which might be the only one holding it. There are code patterns that allow to code like this in a reusable way. Lookup line allocators. You can allocate resources inside a group and release the group in one fell swoop.
- mananaysiempre 4y ago
  > what if this code becomes a library and is integrated as part of a long-lived program Cue one of my favourite comments[1]: /* * We divy out chunks of memory rather than call malloc each time so * we don't have to worry about leaking memory. It's probably * not a big deal if all this memory was wasted but if this ever * goes into a library that would probably not be a good idea. * * XXX - this *is* in a library.... */ (Of course, this consideration should be appropriately downweighted by YAGNI, as threading memory management through prototype or internal utility code can by itself easily force it into very non-prototype territory wrt effort.) [1] https://github.com/the-tcpdump-group/libpcap/blob/2180b6e56a5538c3c3720f22cc3491f02b5276e4/gencode.c#L220-L227 https://github.com/the-tcpdump-group/libpcap/blob/2180b6e56a...
swinglock 4y ago
If you track and free all allocations diligently, you can also use tools to automatically find accidental memory leaks. If everything is a memory leak then useful tools become less so.

teo_zero 4y ago

I always use this technique. It make no sense to free() all the memory just before the exit(). But the prerequisite isn't whether the program is short-lived, but rather that the memory usage pattern is "alloc often, free at the end".

simonkagedal 4y ago
With ”short-lived”, I rather meant something like: ”does one job and then exits”, as opposed to something more dynamic – of course, that it takes a long or short time to execute isn’t by itself relevant.

rui314 4y ago

It caused a flame war, so #1 factor is not negligible.

simonkagedal 4y ago
Haha, I bet! If you happen to have the link, I’d be curious! (And let me take the opportunity to give kudos, this looks super cool!)

liuliu 4y ago

If you know it will always be short lived, that's fine. But even compilers are not strictly short lived nowadays. Both Swift and Rust (I think) maintains a daemon process to assist incremental compilation.

simonkagedal 4y ago
Good point!
SpaghettiCthulu 4y ago
Rust doesn't use a daemon process, it just caches on disk.

_flux 4y ago

It can be quite painful to add them afterwards and while the program might now be shortlived, this might not hold true in the future. And just maybe if one doesn't want to deal with manual memory management, then pick a tool/language that doesn't require it? Maybe a practical alternative to this—that would still reap the performance benefits—would be to have an allocator that postpones frees until certain time (or e.g. number of bytes allocated) has been passed since the start of the program, and after that point works like normal alloc/free. Actually this is not far from how garbage collecting languages work..

SpaghettiCthulu 4y ago
Arena allocators are pretty common for that.

leni536 4y ago

As for C++, memory is not the only resource you can leak. When you leak, then you leak objects with it, and they can hold on to other resources that you might want to clean deterministically. Having said that nothing stops you from replacing the global allocation functions, so that deallocation is noop. But your program, and especially libraries should still match up malloc/free, new/delete and allocate/deallocate. Also your default malloc probably does a bunch of bookkeeping that is eventually only used by free. Once you decide that you won't call free or use a noop free, then there are potentially better candidate implementations for malloc as well.

Kukumber 4y ago

because computers are not "single task", and you cli is not the only thing that's running also memory cost money, no big deal for your machine, but scale this to a fleet of thousands of machines and it start to cost big money then people wonder why their burnrate is indecently high

unwind 4y ago
Huh? Modern OSes will of course free the memory (as well as any other resources) when the process exits. If you know your program has limited runtime you can treat standard heap allocation functions like an over-engineered arena allocator. :)
simonkagedal 4y ago
I did not mean the cli itself (such as bash), but small programs it executes (such as ls). Also not arguing for the practice as a general strategy, but feels like it could have a place!

astrobe_ 4y ago

In my experience it is about code reuse and/or maintainability - what if this code becomes a library and is integrated as part of a long-lived program? It would be risky a posteriori to retrofit a proper memory management. And perhaps, there's something about programming habits. We hear often enough about C having not enough safeties, and one way to mitigate the issue is having "safe" habits. Kind of like how you activate your blinker when you turn even when there's nobody around; if you don't, you might forget to activate it when it matters.

simonkagedal 4y ago
Yep, I was thinking that there could be a good and bad form of my first argument, and this sounds like the former!
jstimpfle 4y ago
It's considerably more work to get a piece of software in shape for use as a library. Matching all callocs with frees is not a huge amount of work, but if you know that there's no requirement to do it, you might as well save the typing. Kind of like I admit I often don't active the blinker when nobody is around, because it means a little inconvenience and it requires you to get one hand off the steering wheel, which might be the only one holding it. There are code patterns that allow to code like this in a reusable way. Lookup line allocators. You can allocate resources inside a group and release the group in one fell swoop.
mananaysiempre 4y ago
> what if this code becomes a library and is integrated as part of a long-lived program Cue one of my favourite comments[1]: /* * We divy out chunks of memory rather than call malloc each time so * we don't have to worry about leaking memory. It's probably * not a big deal if all this memory was wasted but if this ever * goes into a library that would probably not be a good idea. * * XXX - this *is* in a library.... */ (Of course, this consideration should be appropriately downweighted by YAGNI, as threading memory management through prototype or internal utility code can by itself easily force it into very non-prototype territory wrt effort.) [1] https://github.com/the-tcpdump-group/libpcap/blob/2180b6e56a5538c3c3720f22cc3491f02b5276e4/gencode.c#L220-L227 https://github.com/the-tcpdump-group/libpcap/blob/2180b6e56a...

swinglock 4y ago

If you track and free all allocations diligently, you can also use tools to automatically find accidental memory leaks. If everything is a memory leak then useful tools become less so.