Who Owns Virtual Memory and Who Allocated it?

In this section we take a look at the primary system structures used in memory management and how they are located using the Dump Formatter and Kernel Debugger. These structures are:

The memory arena record (VMAR)

The memory arena header record (VMAH)

The memory object record (VMOB)

The memory context record (VMCO)

The examples worked in this section illustrate:

how to find all memory allocations made by a given process and what executable made the allocation.

how to determine ownership of non-system memory.

the use of memory objects, pseudo-objects and system objects.

Memory allocations have many attributes, included among which are:

data or content

location or address

size

ownership

requestor

The composite set of attributes associated with a memory allocation is refered to as a memory object. OS/2's virtal memory manager tracks memory objects using arena, object and context records.

We start by looking at the arena record, which is used to record virtual address assignements to memory objects.

The entire system address space of 4 gigabytes is partitioned into three types of memory arena:

System Arena

This is the range of virtual addresses where system information and ring0 code executes. Typically device drivers, file system drivers and the OS2 Kernel executes and uses data assigned to the System Arena. There is just one instance of the System Arena. It is assigned the virtual address range from 512 Mb to 4 Gb.

This is the range of virtual addresses assigned to shared objects. Shared data objects come in two varieties:

Global data

Such objects exist as unique entities. Their address range and data content are common to all accessing processes. This is achieved by using common page tables in all processes.
Instance data
Such objects share the same address range, but exist as distinct data instances in each acccessing process. Page table entries for instance data are specific to each process.
Code objects from DLL modules are also consigned to the shared arena.

In general processes are not given automatic access to instance or global data. Access is granted either implicitly by the system loader because of calls to other DLLs or explicitly by use of the DosGiveXxxx and DosGetXxxx set of APIs.

There is just one shared arena, which reserves initially virtual memory addresses from 304Mb to 512Mb. This may be expanded by lowering the lower bondary. The current address range assigned to the shared arena is managed by a special arena record called the boundary sentinel arena record.

This is the range of virtual addesses used to map objects that are unique to each process. A private arena therefore exists for each process. In general the page tables of each private arena will map to unique real storage frames. An exception to this is with code objects. Since code segments are always read-only then if more than one process is running the same executable module their page tables will map to a common set of real storage frames for the code segments of the executable module.

Private arenas are assigned an initial address range from 64k to 64M. This may be expanded upwards as more memory is allocated. The current size of a private arena is tracked by a special arena record called the sentinel arena record.

The private arena upper boundary and shared arena lower boundary may grow towards each other but not overlap.

These worked examples now follow:

Exploring arena records

Exploring object records

Finding who owns memory