I’ve got the situation where the cycle of loading and then closing a document eats up a few Mb of RAM. This memory isn’t being leaked as something owns it and cleans it up when the app exits (Visual Leak Detector and the Mac Leaks tool show agreement on this). However, I’d like to find out where it’s going. I’m assuming it’s some sort of cache in the application that gets populated when the document loads but not freed when the document is closed. Which methods or tools could I use to find out where these allocations are being made?
UPDATE:
Following Hans’s post I added a loop to the app to repeatedly open and close documents. I found that there was an initial jump in memory usage (‘Private Bytes’ as reported by Process Explorer) after loading the first couple of documents, but then it no longer increased every time. So this suggests that there are no new allocations, and the apparent increase is likely to be mostly due to an artefact of paging.
I’ve also taken a closer look at Instruments on the mac, which was useful for seeing where allocations were happening: create an Instrument composed of the Allocations and Leaks tools then add a heap snapshot at the start and end of a cycle and in the Heapshots list it’ll show all the allocation deltas relative to the last snapshot. This suggests that on the Mac the memory allocations were increasing but it was due to internal caches such as CoreGraphics drawing, over which we have little control.
Working from the assumption that it is actually RAM you’ve measured: sure this is entirely normal. Your program is actively addressing virtual memory pages when loading a document, they’ll get mapped to RAM. They’ll stay there until another process needs to have pages mapped to RAM. Some operating systems trim the working set pre-emptively, on Windows for example when the app’s windows are minimized.
If it is actually virtual memory pages you’ve measured: that’s normal too. After you release the memory, the heap blocks are added to the list of free blocks, ready to be used by the next memory allocation. If releasing the memory happens to free an entire range of pages then the memory manager has an opportunity to unmap that range. It doesn’t happen often and its an implementation detail of your memory manager how aggressively it does so.