Joseph Galbraith wrote:
> The heap manager prevents this from being true.
>
> Especially with lots of small allocations of varying
> life-times, pages may never actually freed.
>
> Even if a page becomes unused in the heap, the heap manager
> may not free it to the OS if it doesn't have very many free
> pages or other thresholds aren't met.
Ok, a workaround for this could be to set the heap manager's decommit
threshold to something low, say.... 4 kilobytes for example.
> And even if it did vanish from the working set, that doesn't
> mean it was freed... only that the OS wanted the page
> for something else.
>
> An interesting tidbit: last I heard, with a regular application,
> minimizing it dumped it's entire working set.
Right :-).
Forget about the working set, then.
With the workaround mentioned (lower decommit threshold), pages should
be decommitted quickly. And once decommitted, the pages should
disappear from the "VM Size" counter in Task Manager.
Then there's the shared memory stuff that Stefan mentions, but luckily
shared memory regions are excluded from "VM Size" in Task Manager.
Ok, so this is the debugging options:
* Muck about with the heap manager configuration. You'll get insane
memory fragmentation (at least until you reset the setting and
reboot), but pages will be released from TSVNCache quickly and you
should be able to follow memory usage accurately.
* Beg Stefan to implement something in TSVNCache that shows you the
amount of heap in active use by the cache... A call to
OutputDebugString once in a while would probably do, or a line of
output in TSVNCache's log window at clever intervals.
Hmm.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Feb 6 22:16:12 2006