The amount of memory available to a test system is determined by several factors, including operating system limitations, bitness of the test system process, and whether code modules are being executed in-process or out-of-process. This document explains these factors so that you are aware of how your test system configuration affects the amount of memory your test system can use during execution.
The Windows operating system enforces memory limitations on the amount of memory available to a process running on the system. These limitations are affected by the bitness of the operating system and the bitness of the process. The table below lists the amount of memory available to a process based on these factors.
| Process Type | 32-bit Windows Operating System | 64-bit Windows Operating System |
|---|---|---|
| 32-bit Process | 2 GB* | 2 GB* |
| 64-bit Process | N/A | 8 TB |
*This limit can be increased by setting the Large Address Aware flag for the process. See the section below for more information.
If you are running a 32-bit process, you can increase the amount of memory available by configuring TestStand to be large address aware. Enabling the Large Address Aware flag will increase the maximum available memory to 3 GB for a 32-bit Windows OS, and 4 GB for a 64-bit Windows OS. For more information, refer to Use Large Address Aware Flag for 32-Bit TestStand Processes.
Because memory limitations are imposed on each process individually, you can use out-of-process execution to increase the amount of memory available to the test system. Executing a portion of test code in a separate process will allow that code to access a separate memory space from the memory being used by the rest of the test system. There are several ways in which you can implement out-of-process execution in your test system architecture.
If your test system contains code modules which require a large amount of memory, configure the code modules to execute out-of-process to access a separate memory space from the TestStand process itself. This increases the amount of memory available to the code modules and lessens the likelihood that an out-of-memory error will occur during execution.
The LabVIEW and LabWindows™/CVI™ module adapters can be configured to execute code modules out-of-process. For more information, refer to Use 64-Bit TestStand to Execute 32-Bit LabVIEW Code Module.
There are two downsides to configuring the adapters to execute code modules out-of-process:
In TestStand 2014 and newer, you can configure a test sequence to execute out-of-process in a separate instance of TestStand running on the same computer, which allows the sequence to access a separate memory space from the original TestStand process. You can also use this approach to execute a sequence in the opposite bitness of TestStand, although this approach requires both 32-bit and 64-bit TestStand to be installed on the computer. For information, refer to Execute TestStand Sequence Across Bitness.
Note: Using remote sequence calls to execute test sequences out-of-process has a performance penalty compared with in-process execution. It is also more difficult to debug a sequence executing out-of-process.
It is important to recognize that an out-of-memory issue could occur before the memory limit of the test system process is reached. As the test system executes, blocks of memory are allocated and used to store code modules, variable values, and other data. When the code modules are later unloaded or data is cleared, the blocks of memory are deallocated and become available for use.
The result of this allocation and deallocation is that the free memory space of a process often exists as multiple smaller blocks of memory spread throughout the total memory space of the process. This concept is known as memory fragmentation. Memory fragmentation can result in an out-of-memory error if the process attempts to store a large array or other piece of data in memory and is unable to find a free block of memory that is large enough to store the data.