There is memory allocated when an execution is run for many different reasons. Please be more specific as to which memory you are referring. Choose one of the following (or add your own if I have forgotten one).
1) Memory used by result collection (to store results under Locals.ResultList while an execution is running). These are typically freed once the process model is done processing them typically for report generation or database logging. By default the process model processes them between runs of the mainsequence on the UUT. These results are also freed when the execution completes (i.e. stops running). If you are not using a process model or do not need results for specific steps or sequences you can disable result collection on a per-step, per-sequence, or global basis.
2) Memory used to keep the sequences and executions themselves in memory. These datastructures stay in memory as long as you have a reference to them. One additional twist with .NET is that you might not think you have a reference to them, but you really still do because .NET hasn't gotten around to garbage collecting the references yet. You can force garbage collection as follows with the following code:
public static void DoSynchronousGCForCOMObjectDestruction()
{
// To make sure activex refs are synchronously released
// we need to call GC.Collect() and GC.WaitForPendingFinalizers()
// at least twice, according to the following document:
// http://msdn.microsoft.com/en-us/library/aa679807%28v=office.11%29.aspx
// The reason we have to do it twice is that the the first call
// might just sweep the objects into generation 2 rather than collecting
// them immediately.
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();
}
3) Memory used by code modules being loaded. This memory is freed when the step settings on your code modules say to unload your modules, but the behavior is somewhat different depending on the adapter. Some adapters can unload code modules on a per-code module basis, but the .NET adapter can only unload code modules when all code modules and .NET objects created by the .NET adapter are no longer supposed to be loaded or referenced. That is because in .NET the only way to unload code modules is to unload the appdomain containing them. TestStand uses a single appdomain for the .NET adapter and unload that appdomain when all .NET code modules referenced by the adapter are unloaded and all .NET references gotten from those code modules into TestStand are no longer in scope.
Hope this helps explain things.
-Doug
