About Module Load / Unload ...

[manu.NET]

Hello,

Is there any technical documentation about module Load/unload other than the TestStand reference manual ?

I would like to understand what is really Load and Unload ?

• For Packed Libraries
• What is a module for a packed library ? The whole library, only a VI interface ?
• Can a VI be unloaded and not others VI in the same Library ?
• For VI calls
• For DLL
• • What is a module for a DLL call ? The whole Dll, only a function interface ?
  • Can a function be unloaded and not others functions in the same DLL ?
• For Dot net calls
• • What is a module for a packed library ? The whole assembly, only a function interface ?
  • Can a function be unloaded and not others functions in the same assembly ?
• How does the global variables (FGV, Singletons, static membres ... ) behave in case of a module unload )

My question is to understand a little more the memory management of modules, in order to create reusable step types, without having to manage the memory !

For DLLs, packed libraries and dotNet assemblies, is it better to create a big library containing everything, or multiple libraries per functionnal familly ?

=> Does a big library takes less space in memory than multiple little libraries ?

For step creation, what is the best for memory management ? (The less memory consumer)

• Packed libraries
• Dlls
• Direct VI calls
• DotNet assemblies

It would be interresting to be abble to folow the memory used by the loaded modules : Trace toolKit for TestStand

In the Teststand API, is there a way to follow the memory taken by the loaded modules ? Get the list of the loaded modules ? .... a way to create my own memory debugger ?

Thanks.

Sorry for my bad english !

Manu.

[Norbert_B]

Manu,

i don't think that there is no more documentation available other than the manual itself.

My experience/impression is that unloading a module simply releases the reference to the module. Whatever happens then is a result of the runtime engine of that module depending on several factors.

In essence, it's all about lifetime management and reference lifetime.

In order to elaborate on this a small example using ActiveX:

Microsoft Excel provides an ActiveX interface you can use in LV. Implement a small VI which opens the Automation RefNum to Excel_Application and set the property "Visible" to true. Using an event structure configured for a "Quit" button event will keep the VI running until the button is pressed. In that case, close the Automation RefNum to Excel_Application.

1. Run this VI and observe what happens. Without interfacing with Excel, press the Quit button in your VI. Again, observe what happens.
2. Now re-run the VI, go into the Excel window and create a new workbook there (Ctrl+N). Swap back to LV and press the Quit button.

There is a difference in behavior in above mentioned tests:

In the first case, only LV has a valid reference to Excel. So when LV finishes the VI and "shuts the reference down", the Excel_Application will close as there is no other valid reference left in memory.

In the second cas, creation of the workbook creates a 'valid' reference in the Excel Application Window. So now there are two valid references in memory. Closing the on in LV still leaves one valid reference (the Excel window!) therefore, Excel stays open.

It is very much the same for the modules in TestStand: releasing the reference to the module lets the runtime chose if the module is unloaded or not. If there is no other reference to this module in memory, it is very likely the module is indeed unloaded; but we have seen incidences where this didn't happen. But again: That is not business of TestStand anymore.

For your questions:

LVLIBP and DLLs (ANSI C and .NET alike) are "one" module. As long as there is a single reference left to it (so to any function inside it), the whole module will stay in memory. If the last reference is released, it is likely that the module is unloaded, but there is no guarantee.

VIs are a difficult topic. If it is "top level", releasing the VI most often unloads it. If the VI is used from other code (e.g. in other VIs which are in memory), the VI stays in memory.

Also note that lvlibs (and descendants like lvclass) behave like lvlibp and dll concern referenced code.

I think the biggest challenge is not reducing memory as much as possible but to find the balance between speed of execution vs. memory consumption.

Norbert