Some memory questions

[Tedd]

1. Memory allocated to a process is usually cleaned up for you on exit; however, there are some circumstances where this can't be done correctly.

Tedd, do you have any reference for this statement? Logic says the heap gets discarded completely on ExitProcess, but I have indeed, on rare occasions, seen my PC act in slow motion after a memory-hungry program exited. I'd really be curious to get an explanation for this behaviour. Google was no help so far..

Nothing concrete, I'm afraid, just previous experience. I was working on one program that appeared to work perfectly fine, but after numerous runs, the system gradually became slower until it became unusable and I had to reboot. After eventually finding the leak, there were no more problems.
In general, private heap allocations can be cleaned up easily; the problems start once memory/objects are shared or passed between processes and certain DLLs. Anyway, why would you purposely NOT free memory, other than to save a few milliseconds on exit (really, is that important to you??)

2. As memory is automatically cleaned up on exit, you can't rely on leaving allocated blocks 'open,' and due to the separation of process memory spaces, another process will not even be able to see your memory.

Don't take that as an offense, please, but that phrase is really difficult to understand. Maybe you could elaborate a little bit, not only for Paulo.

It was a reference to the way Paulo was thinking about what he wants to do. Leaving memory blocks 'open' (like leaving files open) after your process has exited, so that another process can retrieve the same memory blocks and use them. Of course you can't do this because abandoned memory blocks should be freed by the OS when you exit; and even if you could leave them open/alive, one process can't see into the memory space of another process, so it still wouldn't work.

What you have said about laggy performance after exiting a process is due to the OS doing what is basically lazy cleanup.

Yes, that was my suspicion, and it probably has to do with writing zeroes to physical memory to make it ready for the next process. But I'd be grateful for a link where this behaviour is documented, and why it can take several minutes :(

Cleanup is probably done lazily, but don't expect it to be officially documented anywhere (inside info, trade secrets, can change between versions.)
Zeroing pages will be done with a background kernel thread so it shouldn't affect performance (unless there is suddenly a huge requirement for pages and the zeroed pool is already empty.)


Anyway, you can avoid all of these and many associated problems simply by cleaning up after yourself! 8)

[jj2007]

Anyway, why would you purposely NOT free memory, other than to save a few milliseconds on exit (really, is that important to you??)

Actually, my Exit macro cleans up very thoroughly all arrays and strings. The situations where my system slowed down were caused by exceptions. But AFAIK the OS cleans up even after exceptions, right?

[dedndave]

not exactly the same as memory allocation....
try not deleting GDI objects
or worse, not setting a DC back to original state before deleting it

[Paulo]

Interesting discussion.
The reasons for my original question was to establish:
1) How good is windows at cleaning up
2) What happens to allocated memory if an app crashes before releasing that memory.

Judging by the answers, I have to assume that the cleaning up process used by the OS is not very good
and any memory not released by an app is pretty much
unusable until the next reboot.

[Tedd]

Interesting discussion.
The reasons for my original question was to establish:
1) How good is windows at cleaning up
2) What happens to allocated memory if an app crashes before releasing that memory.

Judging by the answers, I have to assume that the cleaning up process used by the OS is not very good
and any memory not released by an app is pretty much
unusable until the next reboot.

Memory that is allocated by you and used only by you will be released correctly - whether you 'forget' or if your program crashes.
Sometimes, when memory is shared between processes (usually by/via DLLs, since they are automatically shared across processes), it's possible to create situations where windows is not sure if the memory should be released - so the memory is kept, just in case (it would be released when the DLL is freed, but when every process uses that DLL, this won't happen until system shutdown.) This was particularly noticeable in earlier versions of windows, but has improved since, so it should be more difficult to achieve.

[Paulo]

Hi Tedd
That makes perfect sense.
Thank you.