Hacker News Reader

Comment by enriquto | Hacker News Reader

This is the core idea:

> It is [...] entirely optional to call free. If you don’t call free, memory usage will increase over time, but technically, it’s not a leak. As an optimization, you may choose to call free to reduce memory, but again, strictly optional.

This is beautiful! Unless your program is long-running, there's no point of ever calling free in your C programs. The system will free the memory for you when the program ends. Free-less C programming is an exhilarating experience that I recommend to anybody.

In the rare cases where your program needs to be long-running, leaks may become a real problem. In that case, it's better to write a long-running shell script that calls a pipeline of elegant free-less C programs.

View on HN

Reminds me of the HFT shop that built in Java and simply turned the garbage collector off. Then when the market closed they would restart the process for the next day.

Or the missile firmware where the missile is going to explode before they run out of memory:

https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...

There was a certain Space Shuttle program that never returned from interrupt. At the end of its interrupt handler, it would just spin. The next interrupt would just add to the call stack.

What happens when it runs out of stack? It just resets the stack pointer back to the start.

Using warhead explosion as garbage collector might seem like a clever hack, but all it takes is an upgrade by a different team (say, adding a new engine, or longer-range sensors, or repurposing a surface-to-air missile for a surface-to-surface role), and suddenly your guidance software runs out of memory before it explodes, and your missile falls onto an an elementary school or hospital.

You can probably double the ram (or more) again by then.

Assuming you know you have to do it.

I assume they would test the missiles before attesting to its range

But sir!! They were nazi orphans!

Related: the Ariane 5 rocket failed on its maiden flight because it reused code from its predecessor, which made an assumption that didn't apply to the higher-performance Ariane 5.

https://en.wikipedia.org/wiki/Ariane_flight_V88

Seems like a mitigation for this kind of issue would be to simulate the inputs to the system for the expected flight duration.

IIRC it was the higher acceleration value of Ariane5 that the old code wasn't expecting that caused the problem. Some fuzz testing could have worked, I suppose.

I would imagine a simulation would factor in the higher acceleration

Except it was worse:

1. The module that failed actually was no longer in use for that part of the flight.

2. The acceleration for the part of the flight where it was in use was within the parameters.

3. Instead of just ignoring / clamping the out-of-bounds values, the no-longer-needed module sent a big error dump.

4. That error dump was sent to the next module in-line, which was expecting...I think numbers, but certainly not big textual error dumps. And so that failed as well.

5. I don't know if that second module was needed.

So had the module just (a) processed the incoming data normally or (b) clamped the values silently or (c) dropped the out-of-bounds values silently, the Ariane 5 would not have exploded.

Instead it did the "make it impossible to represent invalid states"-thing and exploded.

While I understand the appeal of that idea, I think it is overrated with any software that has to interact in some way shape or form with the real world, however indirectly. Because programmers tend to have a pretty limited understanding of what states are valid or invalid in the real world.

(See also: the "falsehoods programmers believe about XXX" series)

> and your missile falls onto an an elementary school or hospital.

Then you just say terrorists were hiding inside…

God, that email takes me back to days when email was much higher signal-to-noise and sig lines were for color, not credentials.

It’s available from Java 11 as the Epsilon GC.

I had a friend who worked for one of the big Market Makers, and he told me that they would indeed turn the GC off, but what they'd do is just pre-allocate everything into bigass arrays before-hand, and have incrementers to simulate the "new" keyword. They might do this in something more or less like a threadlocal to avoid having to deal with locks or race conditions or anything like that.

A lot of game engines do this, avoiding the cost of a malloc lookup by just allocating everything as a stack

Seen some audio engines that do this too. You can come up with an elegant non-blocking lock free allocator and pass updates from the user thread out to system and reserve the memory, or you can just up front allocate everything that's needed.

If it's a fixed function synth, sometimes just allocating everything up front makes more sense.

Kernel drivers, too. Especially the DMA buffers for devices that don’t support scatter gather: if you don’t allocate them at driver startup, you might not be able to find enough free contiguous regions later. Although maybe that’s not as big of a deal these days, since both Windows and Linux can relocate physical pages.

I remember seeing a Java game engine that included a container that you were supposed to dump unused objects into to prevent GC from running in the middle of a level. At the end of the level, you could empty the container, and let the GC run during the loading screen or whatever.

It was a deliberate design choice that was surprisingly close to what the original article describes.

This is called bump or arena allocation, depending on how you want to define it.

Sometimes also referred to as Object pools.

This is like going back to malloc and free but using array indices rather than pointers, and each type has a fixed-size heap. We did it in one Microsoft service because the very first .NET releases had slow GCs.

One could argue that pointers are just array indices, where the array is your whole address space, and you only get the one array for all your types.

It helps that pointer-to-T is a distinct type, where (apart from Ada) index-into-array-of-T is just like any other integer.

Standard approach in systems for critical applications like aerospace: https://www.quora.com/How-does-SpaceX-handle-memory-manageme...

it is somewhat common in garbage collected langages to fight the garrbage collector like that. Sure manual free probably adds up to more CPU time, but it is more spread out and thus not noticable (normally, real time still cannot allocate in the sensitive areas)

Many online games regularly schedule a downtime often to simply restart the process and "solve" moderate memory leaks.

I’ve done something similar in one of our production services. There was a problem with extremely long GC pauses during Gen2 garbage collection (.NET uses a multigenerational GC design). Pauses could be many seconds long or more than a minute in extreme cases.

We found the underlying issue that caused memory pressure in the Gen2 region but the fix was to change some very fundamental aspects of the service and would need to have some significant refactoring. Since this was a legacy service (.net framework) that we were refactoring anyway to run in new .NET (5+), we decided to ignore the issue.

Instead we adjusted the GC to just never do the expensive Gen2 collections (GCLatencyMode) and moved the service to run on higher memory VMs. It would hit OOM every 3 days or so, so we just set instances to auto-restart once a day.

Then 1 year later we deployed the replacement for the legacy service and the problem was solved.

Early lisp machines had garage collectors that were so slow, that this was done on workstations.

Hilarious!

But I remember the first time I saw such a program which never freed anything: jitterbug, the simple bug tracker which ran as a CGI script.

It indeed allows a very simple style!

Meanwhile, use ccan/tal (https://github.com/rustyrussell/ccan/blob/master/ccan/tal/_i...) and be happy :)

I did a watch face on pebble once... the programming style was "uncommon" when you're hardcoding the ONE watch face that is currently rendering the screen. It "felt" very leaky and illegal... but it's a watch face with limited functionality, so... shrug?

A professor actually told us that freeing prior to exit was harmful, because you may spend all of that time resurrecting swapped pages for no real benefit.

Counterpoint is that debugging leaks is ~hopeless unless you have the ability to prune “intentional leaks” at exit

> debugging leaks is ~hopeless unless you have the ability to prune “intentional leaks” at exit

Not in general. It depends on your debugger. For example, valgrind distinguishes between harmless "visible leaks", memory blocks allocated from main or on global variables, and "true leaks" that you cannot free anymore. The first ones are given a simple warning by the leak detector, while the true leaks are actual errors.

I had to debug a program that did just that once, long ago, and the fix was to not free on exit. The program's behavior had been that it took ~20m and then one day it ran for hours and we never found out how long it would have taken. Fortunately it was a Tcl program, and the fix was to remove `unset`s of large hash tables before exiting.

Actually that is not too far from reality. Data that will be allocated only once does not need be freed. You really only need to free memory that may increase iteratively. If the memory is not used frequently it will end up on swap without major implications. If it is used during the whole execution, it will only be freed when the program ends; there's difference if it's by a 'free' or by the OS; there's just no difference.

As an example, constant data that is allocated by GNU Nano is never freed. AFAIK, the same happens when you use GTK or QT; there were even tips on how to suppress valgrind warnings when using such libs.

In the not-rare case where you're writing a library, or wrapping a utility, the last programmer's exhilaration is your pain.

If you're writing a library, you're not writing a program.

If you write a C library, it is a good practice to leave the allocations to the library user, or at least provide a way to override the library's allocator. Allowing your user to write a free-less *program*.

Any large program is composed of libraries. They may not explicitly be described as libraries, or imported from external sources, but there will be abstraction boundaries somewhere.

Which means that if you're writing a program, you probably are also writing one or more libraries.

The difference is that if you're writing a program you know the scope of use of all libraries, whether they be externally loaded or internal abstraction boundaries, and also know the scope of use of the program, and can make a call as to whether cleanup during opetation is required.

Not really. In theory you can, but in practice there are parts written by a different team and you don't know the scope of there parts.

I also know someone who maintains some Clinton era encryption. that code is controlled who can know about it as obsecurity was all you were allowed. There are other pathalogical cases where you can't know everything about your program-

Obviously, the "free-less programs" are not a "one size fits all" option. Like pretty much everything in IT and the dev world.

But those parts, if they exist, are irrelevant to the current discussion, because they are not the parts you are writing.

I was specifically thinking of "creating" when I said writing, not maintaining or extending. And yes, while it can still be large enough to have multiple people working on it, then the "you" is actually a group, and of course you will coordinate on what you're doing and can very easily confirm you all understand the boundaries of how the components you are creating interact.

Extending something you did not originally write may be quite different, of course.

Yeah I don’t know how a C library without `_free()` calls would work across FFI (like making bindings).

Why would FFI be an issue?

Maybe you allocate a string and pass it to Rust code. Then the Rust code needs a way to free it (through `drop`).

1st approach) you don't

2nd approach for when you ignore the first) you use a type that doesn't "own" the pointer, and have the FFI side that allocated it free it

3rd approach for when you find out you can't do the 2nd) hope that the "owned" type is actually generic over the allocator used, and make an allocator that doesn't free (or even better, calls the correct free over the FFI boundary). `allocator-api` is the effort in this direction.

It’s important to use the same allocator to free as you allocate with. You can’t assume that the same allocator is linked to both sides, so if you are allocating and then giving something to something else over FFI, you want to make sure you give them a way to call back into you to free.

This is true irrespective of language.

Code gets reused unless you take steps to prevent it. Once upon a time, someone submitting a change to the self-driving car project unknowingly broke Google’s web search engine. Someone else decided that was insane, and that’s why Bazel rules now let you limit who can depend on you in a monorepo.

Early in my career I saw the aftermath of someone trying to deal with this problem. The solution they went with was to replace all allocations in the offending code with a custom allocator and then just throw the allocator away every so often

Was there any way for them to know when it was safe to do so? If not: Wouldn't stopping and restarting the program be better?

Plenty of cases fit the case, e.g. if it's some sort of server, you assign a separate allocator to each request and then purge it once the request is processed.

This solution did not override "free" to free the extra struct, so calling free is in fact not optional but probably a bad idea. Need an extra patch:

    #define free(_) /* no-op */

Best criticism to this tongue-in-cheek solution yet. I’ll add my own more minor criticism: it will explode if the leaksaver struct allocation ever fails because it doesn’t check the result.

That does it. I am not going to use it.

Nitpick: for maximum source compatibility, use this instead:

    #define free(_) ((void)0)

Technically _ needs to be evaluated by the macro to support cases like free(p++).

hmm right... wouldn't this work then?

    #define free(e) ((void)(e))

The Zig compiler does this on purpose in some cases, iirc. Free can be a waste of time if the program is going to die in half a second from now.

Yeah, I first came across this strategy as a performance optimization in something Jared Sumner wrote about Bun (which is written in Zig).

Link to devblog article/tweet?

Can't find it now, sorry. Can't remember if it was in a tweet or if it was an offhand comment in Bun documentation somewhere.

The go guys knew this all along, because if I understood it correctly this is what happens when you disable the garbage collector. Voila, now you can claim your garbage collector is totally optional and your language fundamentally doesn't require a garbage collector.

[I love golang, and I think it's one of the best languages around. If only it had a truly optional garbage collector. But then again, it wouldn't be go I guess...]

>In the rare cases where your program needs to be long-running, leaks may become a real problem.

Where did this idea come from? I have seen leaks where a program can consume all available memory in just a few seconds because the programmer (definitely not me...) forgot to free something in a function called millions of times.

Next thing they do is to optimize the hell out of kernel process management things until it catches up with the overhead of calling a function in a GC language.

The canonical free-less (or no-op free) solution is conservative GC, isn't it? Specifically the Boehm collector..

This is just an arena allocator scoped to the process.

I always thought that was one reason the UNIX terminal login process (with `getty` and `exec` to shell, getty restarting when the shell exits) was the way it was.

> Unless your program is long-running

... or unless someone decides to convert it into a daemon "because of that ticket" and then QA goes all "oh, ah, the routing is dead, the sshd is dead and the whole box is all but bricked, what could've possibly caused that".

Not calling free can bite in short running programs also if memory allocation is done in a loop.

A great way to write horrible programs.

In short: If it works until it crashes, it doesn't work.

TFA is clearly written in jest. The provided code is not supposed to be run in production, just to illustrate how easy is to trick a "leak detector" in your debugger. You just put all your mallocs in a list, and at the end of your program you can free them all.

Yet, the idea of not freeing some memory in your program is not entirely stupid. Unless your memory is allocated inside a loop of unpredictable length, it's not really necessary to ever free it. Worse: the call to "free" may even fall after your program has run successfully. Thus, avoiding the useless (but typical) freeing spree at the end of your program may make it more robust!

Reply on news.ycombinator.com