As you might know, the 80386 and higher processors use 32 bits for all addresses, which allows for addressing 4 GB of memory. This is generally called the virtual address space.

Note that this address space exists no matter how much physical memory is installed on your system. One of the great advantages of the 80386 processor (compared to earlier processors) is that the processor can do the conversion of a virtual address into a physical address in RAM in hardware -- with a little help from the operating system (in our case, &os2;), which must give the processor tables where conversion data is stored.

To be able to manage virtual memory with respect to the various processes that are running in the system, &os2; divides the entire virtual address space of 4 GB into arenas.

 4096 MB -----------------------------------------------------

                system arena

  512 MB -----------------------------------------------------
                shared arena
  variable ---------------+-----------+---------------
                private   | private   | private
                arena     | arena     | arena
                process 1 | process 2 | process 23
    0 MB -----------------+-----------+---------------
The system arena is reserved for code that is running at ring 0, that is, device drivers and the &os2; kernel itself. Normal applications cannot access that memory.

By contrast, the shared and private arenas are available for use by applications.

While the system and shared arenas will always be backed by the same physical memory pages, the private arena is different for each process. Each application has its own private memory (code and data). By contrast, the shared arena is used for code and data that is shared between applications: for example, all DLLs are loaded into that arena.

The border between the shared and private arenas is variable and depends on how much shared memory is used in the system. This is why sometimes the system runs "out of memory" if many DLLs are loaded. In reality, the system is not running out of physical memory (because it would normally expand the swap file); it is really running out of address space.

All OS/2 kernels from 2.0 before 4.5 (the Aurora kernel) had a fixed barrier at 512 MB for application memory. The reason for this was support for 16-bit applications which cannot easily access memory above that line.

This has changed with the Aurora kernel, which allows applications to allocate memory above the 512 MB line if VIRTUALADDRESSLIMIT is specified with a value > 512 in &cfgsys;. The address space now looks like this:

 4096 MB ---------------------------------------------
                system arena
 VIRTUALADDRESSLIMIT ---------------------------------
                high memory arena (shared and private)
  512 MB ---------------------------------------------
                shared arena
  variable ---------------+-----------+---------------
                private   | private   | private
                arena     | arena     | arena
                process 1 | process 2 | process 23
    0 MB -----------------+-----------+---------------
As you can see, the space between the system and shared arenas is called "high memory" and is again divided into shared and private arenas. This memory is only given to applications if they explicitly request this, so enabling high memory only has direct consequences for applications which are aware of its existence. (For example, Java will use this arena if SET JAVA_HIGH_MEMORY=1 is specified in &cfgsys;.).

However, enabling high memory still has side-effects. As said above, this memory cannot be used by 16-bit code. This is why you need the 32-bit TCP/IP implementation (version 4.1 or above) if you use high memory with Java.

In addition, the higher you set the VIRTUALADDRESSLIMIT, the smaller the system arena becomes. This is why raising the virtual address limit may reduce the number of available processes.