Just another generation in the garbage collector.

If anyone is wondering, this is not a joke. Some of the trading systems I've worked on were designed to be restarted every night. The memory didn't "leak", but was designed this way - preallocate all the memory you could need, and its "freed" when you restart at night.

> preallocate all the memory you could need

Well, why did they have to restart if they never made any further allocations? This does not add up.

Because the memory fills up. You pre-allocate a million orders, and send 800k orders a day, leaving only 200k free slots. You're going to run out mid day tomorrow if you don't restart.

Ah, OK. But I would characterize this as an internal allocator that never deallocates. You might as well replace `malloc` and `free` to do the same, and just allocate within the program normally.

Just because you "preallocate" it doesn't mean that you don't implement a poor man's allocator inside the preallocated buffer.

Sure, but calling malloc at runtime is slow and maintaining an allocator isn't very useful if you can just restart the app every night. YAGNI ;)

That just sounds like a memory leak with more words. Is the memory reclaimed/reclaimable? No? Ok then it leaked. If the system were able to reclaim the memory from the order, you wouldn't need to restart it. The memory arena strategy doesnt change that.

It's still a fine strategy. One "formal" name for it I've heard is "null garbage collector". It may feel dirty, but it's pragmatic: if the program runs in cycles with well-defined starts and ends, restarting it reclaims all memory and brings the program to a well-known state.

I buy all the groceries I need for a week. That's realistically achievable (cost, cargo capacity of my vehicle, storage capacity at home, etc.).

I buy all the groceries I need from now until the end of time. That's not realistically achievable, from any perspective.

Allocating all the memory you need for a day is realistically achievable. Allocating all the memory you need until the end of time is not realistically achievable.

The grocery analogy doesn't work. When you're "done" with a particular "grocery", it's gone. It doesn't exist anymore. When you're done using a block of memory, you can use it again and again and again. Assuming you remembered to free it. Groceries work more like write-once memory.

Still sounds like a leak to me.

It's a "leak" only if it creates problems for you, such as slowdown or risk of running out of memory. In this case, there are no such problems - memory use and execution time are both bounded. The memory gets automatically reclaimed when the program restarts (that's the job of the OS, and if it fails at it, you can always reboot the machine).

It's a perfectly fine way of engineering a system.

There's also a variant of this that's been used on missiles - basically, you put enough RAM on the weapon to guarantee it'll hit its target or run out of fuel before running out of memory.

Restarting software once a day to work around memory leaks is real amateur-hour stuff. Mine does it every 10-20 minutes.

The real pros generalized this concept into so-called "supervision trees" - building your system as a hierarchy, where whenever a program misbehaves in any way, it gets restarted by a higher-level program, which itself will also be restarted if it can't get a handle on things, recursively to the top of hierarchy.

(Yes, talking about Erlang/OTP here.)

Yep.

I once was tracking a white whale of a memory leak. Along the way I was able to optimize memory usage of the leaked objects. So I got to the point where I thought maybe the leak was caused by simultaneous read, update, and delete operations on a single key, but by then I'd improved memory usage such that weekly, rather than nightly restarts were needed. The futures markets at the time were 24/7 but with a maintenance period on the weekends, so my boss just told me to leave it and let the restarts garbage collect.