pcache interactions with reset

_From [bruen...@google.com](https://code.google.com/u/109494838902877177630/) on January 10, 2013 11:20:21_

this was PR 214121/case 9686

Probably -persist should disable reset for now until we decide on all the
interactions between the two. A reset today will blow away all persisted
caches and not re-load them, and will also prevent persistence of code
removed that does not come back.

A) Should a reset persist everything prior to deleting it?

B) Should we allow for re-loading pcaches post-reset?
But then, why bother to reset?
We could consider a reset parametrization that only throws out the ibl
tables (including their fake fragments, for -disable_traces), which
would free a significant amount of memory but leave coarse units
including persisted caches ( at the minor cost of course of further
overhead from partitioning the heaps further).

For internally-triggered resets: the only one, aside from the
running-out-of-memory ones, is -reset_every_nth_pending, which does NOT do
a full reset, so pcaches should be safe there.

_Original issue: http://code.google.com/p/dynamorio/issues/detail?id=1051_

No source files, tests, or entry points are named. Start by locating the reset and pcache handling associated with -persist, then resolve the questions about preserving, reloading, or disabling persisted caches and define tests for the chosen reset behavior.

Written by the indexing model from the issue text.