0

I’ve implemented a data structure that defers the free-ing of dynamically-allocated memory until the end of the program. Essentially, it’s an allocation stack that keeps track of all heap-allocations. Then, at the end of the program, all allocations are freed. I can see the obvious pro to this being the fact that I don’t have to worry about free-ing pointers or if I have an accidental double-free. The downside, from what I’ve seen, is that heap memory usage only increases as the program continues execution. Are there any other downsides to this?

Joshua Crotts
  • 5
  • 2
  • 5
    If you're going to wait until the end, then there's no point in doing it at all, since all the process memory goes away automatically when the program exits anyway. – Barmar Sep 26 '22 at 22:48
  • @Barmar I agree, but tell that to the thou-shalt-free-everything zealots (and, OP, you may otherwise be interested in the threads) at [What REALLY happens when you don't free after malloc before program termination?](https://stackoverflow.com/questions/654754) and [Should I free memory before exit?](https://stackoverflow.com/questions/36584062) – Steve Summit Sep 26 '22 at 22:53
  • 1
    @SteveSummit Those same posters would also say that you should free everything as soon as it's not needed. Freeing at the end is just an edge case that they also recommend. – Barmar Sep 26 '22 at 23:02
  • Yes, the only downside is that heap memory usage increases. But, there are a couple of consequences to consider. 1) After you run out of physical memory, the OS will start to use swap memory. That will slow down the computer, and will shorten the life of spinning drives, and solid state drives as well. 2) After you run out of physical memory **and** swap space, your program will be unceremoniously terminated. That's not a very pleasant user experience. – user3386109 Sep 26 '22 at 23:07
  • 1
    Retaining memory to avoid incorrect freeing of memory or incorrect use of freed memory does not avoid those things; it merely changes the consequences of the bugs. The bugs are still present and still can cause errors in your program. – Eric Postpischil Sep 26 '22 at 23:50
  • 1
    If you are keeping track of everything just to free it right before program exit... you might as well not keep track of anything at all and simply terminate the program. You're adding unneeded runtime overhead, the OS will release all memory used by the program once it terminates regardless. – Marco Bonelli Sep 27 '22 at 00:12
  • Memory will still be leaked. Freeing all at the end of the program is not really much different from not freeing at all because the OS automatically frees memory on program exit. – user16217248 Sep 28 '22 at 03:28

1 Answers1

1

The downside is that your program will use more total memory than it actually needs, since every allocation will increase the total memory used, rather than reusing memory that was previously freed. Depending on how long the program runs, this could add up, and slow things down.

As an example, imagine if you did this in a text editor where you edit many files. When you close a window, all the memory associated with that file will still be allocated, even though it's not being used for anything. If you're like me, you keep the editor open all the time, editing various files and closing the ones you no longer need. If it didn't free all the allocations when closing a file, the memory use could grow enormously, since I rarely exit.

Freeing memory as soon as it's no longer needed allows the heap manager to reuse that memory rather than increasing the total memory footprint of the process. While modern systems have lots of memory, both physical and virtual, it's not infinite, and if several large applications worked the way you describe you could run into problems.

There are also applictions that are intended never to exit, e.g. webservers and system daemons.

Do you have a DVR that reboots every day? One possible reason is because the programmers took shortcuts and don't free memory when it's not needed, so the memory just keeps growing, and they reboot to clear the memory before it runs out.

Barmar
  • 741,623
  • 53
  • 500
  • 612