Global allocation table

The global allocation table is a private (static) object, statically allocated inside xmemory.c.

The current implementation of this table stores for each pointer:

• The pointer value.
• The size of the associated memory block.
• The name of the source file and the line number where the allocation took place (optional).
• The type of allocated memory.
• If the block is a swapped VM file: a unique swap file ID and file descriptor.
• If the block corresponds to a mapped file: the name of the mapped file, and a reference counter for this file.

Each of these structures is called a memory cell.

In addition, the global memory table stores various informations about memory allocation since it was first initialized, e.g. total amount of allocated RAM, of allocated VM files, maximum number of pointers allocated so far, etc.

Storing the name and line number of the calling source file is actually performed using the __FILE__ and __LINE__ macros in C. The overloaded calls to memory allocators are the following:

#define malloc(s)   xmemory_malloc(s,   __FILE__,__LINE__)
#define calloc(n,s) xmemory_calloc(n,s, __FILE__,__LINE__)
#define free(p)     xmemory_free(p,     __FILE__,__LINE__)
#define strdup(s)   xmemory_strdup(s,   __FILE__,__LINE__)

This is not useful for the VM mechanism as such, but is an excellent debugging tool for memory leaks. This mechanism is only activated for a sufficient debug level (see below for description of all possible debug levels).

The swap file descriptor and block size are required to unmap VM files. The swap file ID is a unique number delivered to each VM swap file by the memory module. This number identifies the name used for the file on disk, and is used to build the VM file name when the module needs to delete it. See below for VM file name conventions.

In this implementation, the global memory table is statically allocated to contain 8192 pointers (a value that can be modified by editing xmemory.c and changing the definition of XMEMORY_MAXPTRS). This represents about 4 megabytes on a Linux PC, which should be reasonably small compared to the expected data sizes.

Increasing the maximal number of handled pointers will increase the initial memory usage of any process linked against this module, so a tradeoff has to be found.