OS/2 Memory Management

Chapter:Chapter 02 – Inside OS/2 Warp
Subsection: 01. Base Operating System Architecture
Document Number:04
Topic: OS/2 Memory Management
Date Composed: 10-02-96 07:17:56 PM Date Modified: 11-14-98 11:01:56 AM

Intel memory structure

The structure of memory in an Intel processor environment is a legacy of the design inherited from the original IBM PC back in 1981. The Intel 8088 processor used in the PC had a memory address range of 1 MB. At the time, 1 MB was many times the size of the address space provided in any other personal computer. This 1 MB address space was divided by the need to access memory using a segmented memory model into sixteen 64 KB segments. The lower ten of those segments, 640 KB, were provided as user memory to load an operating system and application programs. The remaining upper 384 KB was reserved for BIOS, video RAM, and future use.

In order to ensure backward compatibility for operating systems and programs with the early computers, all Intel based personal computers since have retained this memory structure. Even the 80×86 and Pentium class processors have an identical memory structure in the lower 1 MB. Above the 1 MB address, however, the address space is unbroken up to 4 GB and operating systems and applications can access all of it unencumbered – if the hardware will support that much memory.

It is important to understand that this memory structure is not a result of the design of the 80×86 class of processors; it is an artifact of the design of the original IBM PC.

Figure 1: Memory map of OS/2 in an Intel environment.

OS/2 memory usage

OS/2 Warp can access the entire 4 GB memory address space of the Intel 80×86 processor family. This includes the 80386, 80486, Pentium, Pentium Pro, and all the DX, SX and SLC variants of these processors. When Warp is loaded into RAM at boot time, the OS/2 kernel begins loading at the lower boundary of memory. It fills the lower 640 KB of RAM first, skips the 384 KB of reserved memory address space, and continues loading into the area beyond 1 MB. When OS/2 is running, it essentially ignores the address space between 640 KB and 1 MB

Once the kernel is loaded, the rest of memory is available for use by user application programs. These can be real OS/2 programs, DOS programs, and Windows 3.1 programs.

Paged access to memory

Application programs do not access memory directly under OS/2. To ensure that application programs do not use memory which does not belong to them, memory can be accessed only through the operating system. This is accomplished through the use of page tables. Warp manages the page tables, and memory, with the support of the processor.

Under Warp, all memory is divided into fixed, non-movable blocks called Pages. Warp’s memory manager keeps track of memory usage with the Page Tables. Whenever a program is loaded by Warp, the memory manager creates a page table for that program. The page table is a list of memory pages which belong to the program. The Page table entries also contain information about how the memory is being used and is the basis for the memory protection mechanism of Warp.

Figure 2: OS/2 Warp accesses physical memory through the Page Table. The Page table entries also contain information about how the memory is being used and are the basis for the memory protection mechanism of Warp.
The most important thing to understand about memory management in OS/2 is not how physical address are generated; rather it is how each program’s virtual memory space is isolated from the rest of the programs. Each entry in the page table for a process contains an address pointer to the base location of the physical page of memory represented. It also contains attribute bits which describe how the physical memory is used and what access to the memory is permitted. The attribute bits which are important for this discussion are:

  • Commit When this bit is on, the page of memory has been committed to physical storage, either RAM or fixed disk. The Commit and Decommit bits are mutually exclusive; only one can be on at a time, while the other must be off.
  • Decommit When this bit is on, the memory page has been assigned to the program but, because the program has not yet stored any data in the page, or used it in any way, the page has not been committed to physical memory. In this way OS/2 only uses physical memory resource which is actually needed by a program. This is called sparse allocation. The Commit and Decommit bits are mutually exclusive; only one can be on at a time, while the other must be off.
  • Execute This bit, when on, means that the data stored in the page is executable code.
  • Read When on, this bit means that the data in the page is readable. If off, the data cannot be read.
  • Write When this bit is on, it means that the page can be written to.

Access to any page in a manner which is inconsistent with its attributes causes the Intel processor to generate an access fault. OS/2 has a kernel level process, HARDERR.EXE, which handles these hardware errors from the processor. The hardware error handler determines the cause of the access violation and displays an error message for the user to see. In some cases, where the error occurs in the kernel of OS/2, an Internal Processing Error (IPE), is generated and the system is stopped.

Virtual Memory

OS/2 utilizes what is known as virtual memory. Virtual memory is provides a protected address space to each program running on the computer. From the viewpoint of the program, as shown in Figure 3, it resides alone in a computer address space which is contiguous and sequential. Because this memory space is protected, other programs cannot obtain access to it. Virtual memory can also use available hard drive space as auxiliary storage when the computer’s RAM is all in use. What this means is that when you have 24 MB of RAM in your system, and you are running programs which together require 37.5 MB of memory for executable code and data, you need an additional 13.5 MB of RAM which you don’t have. In OS/2 Warp, the memory manager uses available hard disk space to substitute for that unavailable RAM.

Figure 3: Each Application in a virtual memory system appears to have sequential, contiguous, and isolated memory space.
In fact, the physical memory resource allocated to each application may be neither sequential nor contiguous, and may not even be in RAM. Figure 4 shows that some pages of memory for a given program may be located in RAM, while other memory pages may be located on the fixed disk drive. It is OS/2, or rather OS/2’s memory manager which is responsible for mapping the virtual memory to physical memory resource. The OS/2 memory manager is also responsible for moving data from disk to RAM when they are needed for the computer to work on.

When physical RAM is filled up, and yet more RAM is needed by a program, the OS/2 memory manager transfers the contents of one or more pages of RAM into the SWAPPER.DAT file in the hard drive. Those pages of RAM are then allocated to the program which needs them. Entries for these memory pages are created in the page table for the program which needed them, and the entries show the location of the page in RAM.

When a program attempts to access a page of memory which has been swapped out to the hard drive, the processor generates a page fault and the OS/2 memory manager then retrieves the page from the hard drive and places it into RAM. If necessary to make room for this page transferred to RAM from the hard drive, the OS/2 memory manager will dispose of pages which have been marked as discardable, or will transfer pages from RAM to the hard disk.

Figure 4: OS/2 maps virtual memory to a physical resource, either RAM or fixed disk.
When any application, as a result of a programmer error or an overt attempt by the programmer, attempts to access memory which does not belong to that program, the Intel processor generates an access violation. The processor knows that the memory does not belong to the program trying to access it because there is no entry in the page table for that program for the memory in question. Warp’s error handler interprets this access violation as a Trap 000D error. When a program accesses memory which does not belong to it, the only option which OS/2 allows the user is to terminate the errant program. See Figure 1 in the document “OS/2 Crash Protection” for an example of a program which can crash with a Trap 000D error because it attempts to access memory which does not belong to it.

For any kind of problem with a program which creates an access violation, the error handler first displays a SYS3175 error. To determine the specific problem, click on the button to see the registers. At that point the specific trap error is displayed.