SAP MEMORY ORGANIZATION documentation, setup help and usage info

ARTICLE

General Memory Organization
This section describes AS ABAP memory organization from the perspective of an ABAP program, meaning which memory can be accessed by an ABAP program. For a more general and technically more detailed description, see the SAP Memory Management documentation.
The following diagram shows the general memory organization of ABAP programs up to the level of the internal session :

Application Server
The application layer of an AS ABAP
can be distributed across multiple application servers . If an AS ABAP has more than one application server, these are normally instanced on different computers. It is also possible, however, for multiple application servers of one or more AS ABAP s to be instanced on the same host computer. The transaction
SM51 shows an overview of the application server of the current AS ABAP and which computers it is instanced on. The network name of the computer on which the current application server is instanced can be taken from the system field
sy-host in an ABAP program.
Every application server has access to the central database of the
AS ABAP . Each application server has its own shared memory . The ABAP runtime environment uses the shared memory for programs, program data, and buffers (for example, in SAP buffering
). ABAP programs can store shared objects
and data clusters in the shared memory.

Note
The shared memory is frequently used and may therefore become a sparse resource, which can result in bottlenecks when explicitly storing data from ABAP programs.

User Session
Logging on to an application server opens a user session . A user session is assigned its own memory area of the SAP memory , in which SPA/GPA parameters can be stored. An additional user session can be opened by the program using a Remote Function Call with the destination "NONE" .

Main Session
For every user session, a main session is opened. Each main session is assigned its own memory area of ABAP memory , in which data clusters can be stored. The programs of a call sequence share access to these clusters and the data is retained for as long as the top level transaction of the call sequence.
Additional main sessions for a user session can be opened using a Remote Function Call with the addition STARTING NEW TASK , or by entering a transaction code after "/o" in the input field of the toolbar . A maximum of 16 main sessions are possible per user session. The number of sessions actually possible for a system is determined by the system parameter
rdisp/max_alt_modes , whose default is 6.

Note
The ABAP memory can be used to pass data between the programs in a call sequence
.

internal Session
Each call of an ABAP program creates a new
internal session , in which the called program is loaded.
The memory area of an internal session is known as the roll area , itself divided into the areas heap and stack
. This is where the changeable objects of the program are held. The program data that cannot be changed is stored in the PXA . The roll area contains references to the necessary data in the PXA . Technically speaking, roll areas and the global PXA are stored in the shared memory of the application server where they are administrated by SAP Memory Management .
In one main session, there can be a maximum of nine internal sessions, which always belong to a call sequence . Data from the ABAP memory is always assigned to a call sequence.
On 64-bit platforms , an internal session can theoretically require up to 4 TB of memory. On 32-bit platforms , the theoretical upper limit is 4 GB . The practical upper limit is usually below the theoretical limit, since the actual physically installed main memory is the maximum available and divided up among all users.

Note
Instances of classes, with the exception of shared objects , are located in the internal session. It is therefore not possible to store references to objects in the ABAP memory .

SAP MEMORY ORGANIZATION documentation, setup help and example usage