Comment by ggm | Hacker News Reader

Comment by ggm | Hacker News Reader

Maybe it's just me, but I think people tend to drive by memory leaks nowadays because the footprint of binaries has grown, but the size of ram has grown more-erly. Proper big.

I routinely run on 1TB memory 128 core racks, and I don't worry about free() much.

I'm not humblebragging, I actually think this is lazy (!) and I would benefit from more explicitly thinking about the memory consequences of what I do but there are some things which I used to freak out about growing to GB and now, I regard it as an investment on the future me, running the same thing: It's very likely I've got it in a hash structure of some kind already. I just add columns to the dict() elements.

Down the other end, I recall some friends getting code which I expected to have to run on a major rack host to build onto a small memory model rPi and they said rust did that: allowed them to get rid of the overhang of other languages expectations to runtime size and be explicit about use and free in the heap.

In short, in my discipline, if you don’t free your memory you can eat a TB in 10 minutes. Moreover, if you fragment memory too much, then you’ll start to get segfaults when you want large segments of contiguous memory.

Lastly, the same fragmentation will cause advanced libraries like Eigen to use many small memory areas, and jumping between them kills locality, hence causing you performance losses.

I’m running tasks on (and administering) clusters with similar resources to yours, yet I always treat them like 486DXs with 4MB RAM, because I can’t restart them every week.

I think the relative popularity of managed memory languages has grown and continues to grow. Even C++ is largely "managed" via mechanisms like unique_ptr, shared_ptr, or the standard collections. (Using new/delete directly is more or less a code smell these days.) C will always have a place, but despite working in it from 2011-2021 or so, I just don't use it at all these days. With "owned" allocations, you just don't need explicit free(). You're more likely to see memory leaks via unbounded collection size than actual unreferenced pointers.

Every correct program manages memory. Doing it in a structured way just makes it less bugprone.

I get it. And I do wish some systems were quicker to let the OS clean up after them on exit. For instance, the other day loaded a CSV with about 20 columns and 10M rows into a list of Python tuples so I could poke at them a bit. That took a short while and I was ok with that. I was more surprised when I closed the REPL and it hung for way longer than expected as it freed a couple hundred million objects.

Now it could’ve been the case that some of those objects had a __del__ method that needed to be called or something. Absent that case, I’d have preferred the process just exited and been done with it.

If that were a program that ran synchronously from a shell script, the shutdown GC time would’ve been nearly as long as the data loading time. Maybe Python could benefit from a fast_shutdown_GC function that only calls free() if an object is something with a non-trivial delete method. Otherwise, skip it and let the OS do its voodoo it does so well.

I’m picking on Python here because that’s where I last saw this. The basic idea applies in lots of other cases though.

Luckily for us C programmers do care and track down leaks aggressively.

Tracking down memory leaks is just one of things that valgrind can do.

Well not at that scale, but it isn't uncommon just to malloc/HeapAlloc a whole pile of RAM up front, spew your data structures into it and free it when it crashes / exits. It is a perfectly valid strategy.

In fact I did this a couple of years back on a project I was working on maintaining in win32. It had a complicated memory management scheme for a GUI process that kept screwing up. Turned out it couldn't ever use more than 2MB of RAM so I just allocated 10MB up front at the start of the process and wrote a simple incrementing pointing counter in that allocated block and free'd it at the end like a short life pool. Solved all the issues. Machines it's running on all have at least 16GB of RAM so it's not exactly breaking the bank!

For short-lived programs perhaps. For things like servers that may run for months, leaks are absolutely important.

Even memory fragmentation is a problem for us. We once had a chat server that would crash every 3 months, which we tracked down to memory being fragmented by a less than optimal malloc implementation in glibc. (Since the glibc fix was in the "too hard" category, we reluctantly decided to schedule a restart every month.)

Reply on news.ycombinator.com