The Allocation History tab allows you to control how much memory Memory Validator uses to perform its work.
Depending on the task you are performing you may want to allow Memory Validator to use more (or less) memory than for other tasks.
The less information on deallocations, reallocations and freed data that Memory Validator keeps, the smaller the memory requirements placed on your computer.
Depending on the following:
•the task you are trying to complete using Memory Validator
•your computer's RAM capacity
•virtual memory storage
•the target program being inspected
...you may want to discard some types of data rather than keep it all.
You can optionally discard stack traces for deallocations, reallocations and freed memory, and in each case specify just how much information is kept, with oldest deallocated data being discarded first.
•Discard stack traces for free memory discards information about memory and handle deallocations
•Discard stack traces for reallocated memory discard information about reallocated memory and handle allocations
•Discard stack traces for freed memory discard information about deallocated memory and handle allocations
The default is to keep only the most recent 1000 stack traces in each case.
If you set the count to 0, no traces will be kept, which means MV will use less memory, but this will also mean the Analysis / Query tab will be unable to provide any results.
Deselecting each option will keep all the data for that option. This will use lots of memory as information for deallocated memory is kept until the application finishes and the session is closed. For applications that are being monitored that run for a long time and that allocate and deallocate a lot of memory, deselecting each option will put more memory strain on Memory Validator and in the extreme case will cause Memory Validator to run out of memory.
Normally Memory Validator keeps information about COM Reference counts even after the reference count for a particular object reaches zero. This can be very useful for examining the reference count history when a COM object is deleted because its reference count is Release'd too many times or not AddRef'd enough times.
•Discard COM reference count data when reference count gets to zero discards the relevant data to the freed list (see option above)
Discarding this data is useful when your application is correctly AddRef-ing and Release-ing large numbers of COM objects and you are only concerned with leaking COM objects rather than COM objects being deleted too soon.
Reset All - Resets all global settings, not just those on the current page.
Reset - Resets the settings on the current page.