Memory Limits of TestStand Systems

Overview

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 can be aware of how your test system configuration affects the amount of memory your test system can use during execution.

Contents

Operating System Memory Limits

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 below for information on the Large Address Aware flag.

 

Settings to Increase Memory Limitations for a Process

In some cases, you may be able to increase the amount of memory available to a process by configuring settings for the Windows operating system and for the process itself. You have the ability to configure the following settings:

  • 4-Gigabyte Tuning – On a 32-bit Windows operating system, you can use the 4-Gigabyte Tuning feature to increase the amount of memory available to a 32-bit process. By enabling this setting as well as the Large Address Aware flag described below, you can increase the memory limit for a 32-bit process to 3GB. For information on the 4-Gigabyte Tuning feature, refer to the article 4-Gigabyte Tuning: BCDEdit and Boot.ini on MSDN.
  • Large Address Aware – You can enable the Large Address Aware flag for a 32-bit process to increase the memory limit for the process. On a 64-bit Windows operating system, this will increase the memory limit for a 32-bit process to 4GB. On a 32-bit Windows operating system that also has 4-Gigabyte Tuning enabled, this will increase the memory limit for a 32-bit process to 3GB.

Note: TestStand 2013 and newer automatically have the Large Address Aware flag set for the TestStand Sequence Editor and the provided user interfaces.

For information on the Large Address Aware flag, please see the KnowledgeBase article Using the Large Address Aware Flag with TestStand Applications.

 

Using Out-of-Process Execution to Increase the Memory Limit of a Test System

If your test system requires the use of more memory than the Windows operating system is able to provide to a single process, you may be able to use out-of-process execution to increase the amount of memory available to the test system as a whole. Because memory limitations are imposed on each process individually, 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 may be able to implement out-of-process execution in your test system architecture.

 

Executing Code Modules Out-of-Process

If your test system contains code modules which require a large amount of memory, configuring the code modules to execute out-of-process allows the code modules 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. This is accomplished by configuring the adapter to use the LabVIEW Development System or the LabWindows/CVI development environment to execute code modules. There are two downsides to configuring the adapters to execute code modules out-of-process:

  • Execution Speed – Executing code modules out-of-process is typically slower than executing code modules in-process, because out-of-process execution requires the TestStand Engine to communicate with the external process to instruct it to execute code.
  • Licensing – The development version of LabVIEW or LabWindows/CVI must be installed on the test machine to execute code modules in one of these environments. This requires a development license for each test machine.

For information on configuring out-of-process execution for a module adapter, refer to the Module Adapter section of the TestStand Help.

 

Executing a TestStand Sequence 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 on configuring a sequence to execute out-of-process, refer to the KnowledgeBase article Executing Cross-Bitness Sequence Calls in TestStand.

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.

 

Effects of Approaching the Memory Limit of a 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, and 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.

 

Conclusion

When considering the memory requirements of a test system, you must consider several factors, including the bitness of the operating system and of the test system process, to determine the amount of memory available to the test system process. You should also review settings such as 4-Gigabyte Tuning and the Large Address Aware flag to ensure that your test system and operating system are configured to maximize the amount of memory available to the test system. If you are experiencing out-of-memory issues and expect your test system to require a larger amount of memory, you may wish to architect the test system to use out-of-process execution to take advantage of the separate memory space available to an external process. By considering these factors and designing your test system accordingly, you can lessen the chance of encountering memory-related issues during execution.