1

In Windows NT and later I assume that when a process expires, either because it terminated itself or was forcefully terminated, the OS automatically reclaims all the memory used by the process. Are there any situations in which this is not true? Is there any reason to free all the memory used by a user-mode application explicitly?

Tyler Durden
  • 11,156
  • 9
  • 64
  • 126

1 Answers1

3

Whenever a process ends, all memory pages mapped to it are returned to the available state. This could qualify as "reclaiming the memory," as you say. However, it does not do things such as running destructors (if you are using C++).

I highly recommend freeing all memory, not from a resources perspective, but from a development perspective. Trying to free up memory encourages you to think about the lifespan of memory, and helps you make sure you actually clean up properly.

This does not matter in the short run, but I have dealt with countless software programs which assumed that they owned the process, so didn't have to clean up after themselves. However, there are a lot of reasons to want to run a program in a sandbox. Many randomized testing scenarios can run much faster if they don't have to recreate the process every time. I've also had several programs which thought they would be standalone, only to find a desire to integrate into a larger software package. At those times, we found out all the shortcuts that had been taken with memory management.

Cort Ammon
  • 10,221
  • 31
  • 45
  • On the downside, freeing memory can significantly slow down the process exit, and make the system sluggish during exit. This (used to be?) a major pain with Mozilla Firefox, for example, and also Civilization 5 when run on older machines. It may be preferable to only explicitly free the memory in debug builds, or when explicitly configured to do so, rather than doing so by default in production. – Harry Johnston Aug 03 '15 at 20:19