The following material describes how memory management on Win32 is handled, and briefly describes memory issues of variables.
The Memory Manager manages all dynamic memory allocations and deallocations in an application. The New, Dispose, GetMem, ReallocMem, and FreeMem standard procedures use the memory manager, and all objects and long strings are allocated through the memory manager.
The 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 Win32 virtual memory API (the >VirtualAlloc and VirtualFree functions). The Memory Manager supports a user mode address space up to 4GB.
Memory Manager blocks are always rounded upward to a size that is a multiple of 4 bytes, and always 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 always aligned on at least 8-byte boundaries, or optionally on 16-byte boundaries, which improves performance when addressing them.
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.
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 an application's stack. 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 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.
Copyright(C) 2008 CodeGear(TM). All Rights Reserved.
What do you think about this topic? Send feedback!