Hacker News Reader

Comment by simonkagedal | Hacker News Reader

> 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

View on HN

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.

Yep, I was thinking that there could be a good and bad form of my first argument, and this sounds like the former!

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.

> 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/2180b6e56a...

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.

Good point!

Rust doesn't use a daemon process, it just caches on disk.

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.

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".

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.

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

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!)

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.

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..

Arena allocators are pretty common for that.

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

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. :)

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!

Reply on news.ycombinator.com