The Subsystem always uses local memory. You can set the minimum size of the external MSpace for the Subsystem, networking components, and RTSS processes wRTOS Settings.
Note: If you do not allocate MSpace memory at process startup, your first memory request will be non-deterministic.
Note: Ensure the external MSpace commit size is large enough to support your application’s memory needs. Suppose the external MSpace does not have enough memory to handle application requests. In that case, the allocation requests will fail (when Auto expand MSpaces is disabled), or a non-deterministic call will be made to acquire more memory from Windows based on the expand size set in the wRTOS Settings.
MSpaces logic can be configured to Automatically Expand and/or Shrink. When an MSpace does not have enough memory to fulfill allocation requests, the Subsystem behaves as follows:
- When Automatically expand MSpace is not selected: the request fails with an error indicating that not enough memory is available. You can freeze/unfreeze the process using a registry value. See the TechNote Local Memory Registry Tweaks that Might Improve Performance and Decrease Fragmentation available from the Support Site.
- When Automatically expand MSpace is selected: a non-deterministic call is made requesting more memory from Windows. The size of memory requested will be based on a preset expand size. The default can be set overall through wRTOS Settings or overridden individually using RtssRun with the /e expand_size option or via Task Manager.
The table below describes the configurable MSpace behaviors:
| Behavior | MSpaces | |
|---|---|---|
|
Subsystem Default (via wRTOS Settings) |
Individual Override (via RtssRun and Task Manager) |
|
|
Whether or not to allocate MSpaces memory at process startup |
No |
Yes /i initial_size Note: This does not happen when you use wRTOS Native or Managed APIs to start a process, unless you pass the initial size of the process MSpaces to those APIs. |
|
Whether or not to automatically expand MSpaces on depletion
|
Yes |
Yes /e expand_size |
|
Setting the minimum expandable size of the external MSpace |
Yes |
Yes /e expand_size |
|
Whether or not to automatically shrink external MSpace on freeing |
Yes | No |
|
Setting the minimum size of a process MSpace |
Yes |
Yes /i initial_size |
Note: The expandable feature of a process’ external MSpace can be individually overridden using RtssRun with the /e expand_size option. When the specified /e expand_size is zero, this disables automatic expansion for the process’ MSpaces.
Note: A process’ MSpaces can be configured to shrink automatically at the time of allocation, trimming its pool cache, or freeing memory allocated directly from the MSpaces. This decreases the free memory in the MSpaces. However, it does not shrink an MSpace below its minimum size. You can disable this automatic shrink feature in wRTOS Settings. At process exit, all MSpace memory will be freed.
Regardless of the Subsystem default setting for memory use and the setting for MSpaces, you can monitor the size of the local pool and pool cache for any MSpace using RtQueryProcessMSpace. You can expand the local pool by using RtExpandMSpace. Rather than wait until the MSpace memory is fully depleted, you can force the MSpace to expand. This allows you to decide when to handle a non-deterministic call within your application.
Note: You cannot expand your MSpace or request additional memory from Windows from within a shutdown handler.
All memory allocations explicitly or implicitly in the RTSS application are allocated from the Subsystem or process MSpaces. As a result, the following functions become deterministic and can be called in the shutdown handler:
|
CreateThread* The stack has no guard page for the thread. |
||
