While unthinkable only a few years ago, tumbling memory prices and increasing hard drive capacities have presented PC users the ability to access gigabytes of memory at relativity low cost. As a result of this hardware environment, users are attempting to access large areas of contiguous memory in IDL, but failing for various reasons. This document outlines some of the limitations affecting memory allocation and how they related to IDL. While focused on the Windows operating system, most of the described issues related to any modern operating system.
Limiting Factors When a process requests memory from the operating system, various factors determine if the request will be successful or not. The major factors that can cause a request to fail include:
Physical Memory    The amount of physical memory (RAM) available to the system.
Virtual Memory    The amount of virtual memory
available on the system. Modern operating systems us special areas
on hard drives to present a set of memory to the system that exceeds
the amount of physical memory.
While more sophisticated than this simple description, by using space located on the hard drive the Virtual Memory Manager is able to present a memory pool that exceeds the size of the physical memory on the system.
Free Memory    While the system might have a large
amount of memory available, if that memory is in use, the memory
request will fail. The operating system, other process and other
memory requested by the application effect the pool of available
memory. If a memory request fails, closing other running applications
could release enough memory to allow it to succeed.
Operating System Limits
To present a uniform memory model to all executing processes, modern
operating systems abstract memory addresses used by the systems virtual
memory manager. This abstraction presents each process with the same
memory address space, while allowing them to access different elements
of memory in the VMM. This memory abstraction creates a range of
available memory addresses that is referred to as an address space.
The address space has a specific range of values and it is the limits
of this range that restricts the amount of memory available to the
This is not the only limitation placed on processes on Windows platforms though. System addresses are mapped into this address space, so the available address space is further reduced. The amount of address space is utilized by the system is dependent on the version of Windows NT being used. For Windows NT Workstation and some versions of Windows NT Server, the upper 2 gigabytes of the address space is reserved for the system. This leaves only 2 gigabytes available to the process for use. For Windows NT Server, Enterprise Edition only the upper 1 gigabyte of the address space is reserved for the system, leaving 3 gigabytes of address space available for use by the process. These limitations are summarized in the following table.
When memory is requested from the system a free space of the requested size must exist in the processes address space. If a free space in the address space doesn't exist, the request will fail, even if enough memory exists to meet the request. For small requests this situation hardly ever transpires, but the larger the request, the greater a chance this issue will occur. This scenario is exacerbated when memory fragmentation occurs.
Memory fragmentation takes place when a block of memory is allocated that divides a region of the processes address space, reducing the maximum size of a free block of memory. The following diagram demonstrates this issue.
While sometimes difficult to identify, an indication that memory fragmentation is taking places is when a request for a large block of memory fails, but smaller requests that total the larger request succeed.
Memory fragmentation is often the result of poor software
implementation, arising when the following scenario takes place:
This can occur often when working with large, dynamic memory blocks, so developers must be aware of the issue when designing and implementing software.
Memory Allocation in IDL
The memory allocation system in IDL is very simplistic, leaving main memory accounting and management up to the operating system (malloc() and free()). For efficiency in some areas, IDL does utilize several special sub-systems and methodologies to manage internal memory. Of particular interest are the following:
Temporary Memory    This system is core to the interpreter and used for allocation of memory in a system routine that is called from the interpreter. When memory is allocated using this system, the interpreter will ensure that the memory is returned when the called routine returns. This prevents any memory leaks from occurring in system routines.
Allocating in Blocks    In subsystems that
utilize a common record size and that are extensively used in IDL,
a memory pool is used. This pool will allocated multiple records
at a single time, reducing the overhead of multiple allocation events.
Also, this system maintains a list of free records, so when elements
are returned they are actually recycled.
Central Allocation All memory in IDL is allocated and released through a central set of routines. These routines fulfill the memory request using the system memory allocation functions (malloc() and free()) and also keep count of the memory allocated by the system. This is what provides the information displayed by the "HELP, /MEMORY" IDL command.
Correct Development The IDL Engineering team makes extreme efforts to ensure that the proper memory allocation methodology and procedures are followed when implementing IDL functionality. Efficiency with respect to speed and memory usage is key to IDL's success and as such rigorously checked with every product release.
These systems improve efficiency of memory usage in IDL, but do nothing for overall memory allocation management. This task is left to the operating system since it is more efficient at this operation. As such, all of the aforementioned memory allocation issues can and will affect the memory available to the IDL user. Because of this, the IDL user should be aware of these issues and take appropriate actions as warranted.
If you have any additional questions or comments, please contact Rivix Technical Support for assistance.
Copyright (C) RIVIX, LLC. 1998-2016