3 ms·

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 crash

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!

rwmj 2y ago
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.)