-1

I understand that Clean-Up is good thing to do. I also understand OS internals, so if I know my process is terminating then its memory will be freed. But I like to propose different perspective. I am on the lines it is rather BAD idea to free the memory on exit.

For e.g. I may have allocated large memory which is currently swapped out, if I free it up on exit, it rather needs to be brought to RAM, then free it. If I don;t, on exit it will simply be marked free in one table.

Overall, OSes have changed a lot(basics remain the same), I understand this question can be thought of A_VERY_PLATFORM_DEPENDENT, but from the perspective of application developer today, he is either stuck(?) into some framework, or the daredevil coder, who is working on raw technologies as COM, is significantly relied on, i would call VERY_CONTROLLED_ENVIRONMENT.

For TL;DR: On modern OSes, I think I should NOT perform clean up on exit. If you think I am wrong, why?

PS: I am NOT talking about RTOSes, I meant controlled environment means Windows, Linux and I never meant Device driver development or for that matter OS development.

  • I doubt there is a difference (in regard to needing to bring the pages from SWAP into RAM) between application `free` and SO `free` – bolov Dec 07 '14 at 19:55
  • This was discussed a couple of weeks ago. I will find and mark this duplicate. – Mats Petersson Dec 07 '14 at 19:55
  • 2
    What about non-memory resources eg file handles, kernal handles etc? And if you don't clean up memory based resources how can you be sure that they are not holding "external" handles? – Richard Critten Dec 07 '14 at 19:56
  • 2
    I'd say _cleanup_ should be seen more of about a resource perspective as e.g. db server sessions, exclusive local file locks, etc. than just _freed_ memory (any reasonable OS should regain memory from exited processes of course). – πάντα ῥεῖ Dec 07 '14 at 19:58
  • @RichardCritten handles are closed automatically when process handle table is destroyed. As in case of Kernel handles, can application programmer release them? Or rather request to release them? it does not make sense –  Dec 07 '14 at 20:08
  • Duplicate of: http://stackoverflow.com/questions/677812/is-there-a-reason-to-call-delete-in-c-when-a-program-is-exiting-anyway http://stackoverflow.com/questions/26088499/should-i-delete-big-tree-collections-in-c-at-the-end-of-program-or-leave-that http://blogs.msdn.com/b/oldnewthing/archive/2012/01/05/10253268.aspx Of course, you DO need to clean up lock-files and other resources in some way - I can name more than one application that requires manual intervention to "restart" after a crash... – Mats Petersson Dec 07 '14 at 20:08
  • @all: I don;t understand on what terms you guys are communicating. Either I need to communicate better or I don;t know ANY programming. Doing something which anyway is gonna happen seems damn wrong. Of course from your experiences, you may have encountered a task to do on clean up. But isn;t that your WORK? I specifically mean DEAD_CODE. If there is something that you know you should clean, then u always clean it. But sticking to some standard without completely understanding it - like freeing YOUR_KNOWN_MEMORY is bad. Isn;t it? –  Dec 07 '14 at 20:20
  • I am concluding: 1. Have a common sense(Assumed it to be obvious if you are coding) 2. Don;t do the clean up of the things that u know would anyway be cleaned up. If in doubt google, if then also not found what to do, then cleanup. Please comment if you disagree –  Dec 07 '14 at 20:29
  • 1
    Trying to duplicate OS functionality in user code, in those cases where there is no good reason, is just silly. To shut down an app without faults, all threads must be stopped before resources like memory are released. The OS can easily do this. User code cannot always do this, (eg. it cannot safely and directly stop a thread running on another core than the thread requesting the termination), and even when it can, it's extra code, testing and debugging to duplicate functionality that already exists and has been tested. If there are no bad consequences, just terminate. Stuff valgrind. – Martin James Dec 08 '14 at 03:28

1 Answers1

8

Memory blocks that have been swapped out will be brought in only when you access them. Freeing a block is a "bookkeeping" event, which does not require memory access. You are not going to gain anything by skipping the call to free memory.

Reasons to always free your resources manually on exit are much stronger: it lets you use tools for memory profiling, because you can distinguish unintended leaks from the intentional ones. That reason alone is good enough to recommend against skipping memory cleanup.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523
  • 'That reason alone is good enough to recommend against skipping memory cleanup'. Well, no. It's one advantage. It's not an overriding issue. – Martin James Dec 08 '14 at 03:19
  • @MartinJames All I am saying that this reason by itself is good enough. There may be other good reasons (such as being able to sleep well at night while your code is running critical operations in production) each one sufficiently strong in its own rights. Personally, I find it too risky to release C++ code to production without running a memory profiler on it, and fixing all warnings that it reports. – Sergey Kalinichenko Dec 08 '14 at 03:32