Memory Management

From RAD Studio
Jump to: navigation, search

Go Up to Memory Management Index

This help topic describes the two memory managers that are used on the various target platforms, and briefly describes memory issues of variables.

Default memory manager

The memory manager in use is determined by the target platform/compiler of your application.

The following table lists the default memory manager for each platform.

Platform     Compiler     Memory Manager name



FastMM (



FastMM (






















The FastMM Memory Manager (Win32 and Win64)

The Memory Manager manages all dynamic memory allocations and deallocations in an application. The New, Dispose, GetMem, ReallocMem, and FreeMem standard System procedures use the memory manager. All objects, dynamic arrays, and long strings are allocated through the memory manager.

For Win32 and Win64, the default FastMM Memory Manager is optimized for applications that allocate large numbers of small- to medium-sized blocks, as is typical for object-oriented applications and applications that process string data. The Memory Manager is optimized for efficient operation (high speed and low memory overhead) in single and multi-threaded applications. Other memory managers, such as the implementations of GlobalAlloc, LocalAlloc, and private heap support in Windows, typically do not perform well in such situations, and would slow down an application if they were used directly.

To ensure the best performance, the Memory Manager interfaces directly with the virtual memory API (the VirtualAlloc and VirtualFree functions).

For Win32, the Memory Manager supports a user mode address space up to 2GB.

Note: To increase the user mode address space to 3GB, see Increasing the Memory Address Space topic.

Memory Manager blocks are rounded upward to a size that is a multiple of 4 bytes, and include a 4-byte header in which the size of the block and other status bits are stored. The start address of memory blocks are aligned on at least 8-byte boundaries, or optionally on 16-byte boundaries, which improves performance when addressing them. (See System.SetMinimumBlockAlignment )

For Win64, the Memory Manager supports a user mode address space up to 16EiB in speculation.

Note: Actual maximum allocatable size is depended on CPU implementation and operating system. For example, the current Intel/X64 implementation supports up to 256TiB (48bits), and Windows 7 Professional supports up to 192GiB.

Memory Manager blocks are rounded upward to a size that is a multiple of 16 bytes, and include a 8-byte header in which the size of the block and other status bits are stored. The start address of memory blocks are aligned on at least 16-byte boundaries.

For Win32 and Win64, the Memory Manager employs an algorithm that anticipates future block reallocations, reducing the performance impact usually associated with such operations. The reallocation algorithm also helps reduce address space fragmentation. The memory manager provides a sharing mechanism that does not require the use of an external DLL.

The Memory Manager includes reporting functions to help applications monitor their own memory usage and potential memory leaks.

The Memory Manager provides two procedures, GetMemoryManagerState and GetMemoryMap, that allow applications to retrieve memory-manager status information and a detailed map of memory usage.

The Posix Memory Manager (Posix platforms)

The Posix Memory Manager is used when the target platform/compiler is macOS 64-bit, macOS ARM 64-bit, Linux 64-bit, iOS Device 64-bit, iOS Simulator ARM 64-bit, Android 32-bit or Android 64-bit.

All memory management functions/methods use the Posix system library, as shown in the following table:

RTL POSIX function










Global variables are allocated on the application data segment and persist for the duration of the program. Local variables (declared within procedures and functions) reside in the stack of an application. Each time a procedure or function is called, it allocates a set of local variables; on exit, the local variables are disposed of. Compiler optimization may eliminate variables earlier.

On Win32, an application's stack is defined by two values: the minimum stack size and the maximum stack size. The values are controlled through the $MINSTACKSIZE and $MAXSTACKSIZE compiler directives, and default to 16,384 (16K) and 1,048,576 (1Mb) respectively. An application is guaranteed to have the minimum stack size available, and an application's stack is never allowed to grow larger than the maximum stack size. If there is not enough memory available to satisfy an application's minimum stack requirement, Windows will report an error upon attempting to start the application.

If a Win32 application requires more stack space than specified by the minimum stack size, additional memory is automatically allocated in 4K increments. If allocation of additional stack space fails, either because more memory is not available or because the total size of the stack would exceed the maximum stack size, an EStackOverflow exception is raised. (Stack overflow checking is completely automatic. The $S compiler directive, which originally controlled stack overflow checking, is maintained for backward compatibility.)

Dynamic variables created with the GetMem or New procedure are heap-allocated and persist until they are deallocated with FreeMem or Dispose.

Long strings, wide strings, dynamic arrays, variants, and interfaces are heap-allocated, but their memory is managed automatically.

See Also