SAP MEMORY ORGANIZATION



Get Example source ABAP code based on a different SAP table
  



Sessions and Memory Areas
This section describes the sessions of an AS ABAP in which ABAP programs are executed and the associated memory areas that can be accessed by an ABAP program. For a more general and technically more detailed description, see the documentation Memory Management in SAP Help Portal.
The following figure shows the general organization of sessions for ABAP programs and their memory areas up to the ABAP_ISESS level:
IMAGE ABDOC_Memory1.gif 508 706
ITOC

ABAP_ASINSTANCE
An AS ABAP can be distributed across multiple ABAP_ASINSTANCES . If an AS ABAP is implemented using multiple ABAP_ASINSTANCES , they are usually instantiated on different host computers , which do not have to have the same operating system. However, multiple ABAP_ASINSTANCES of one or more AS ABAP can also be instantiated on the same host computer. ABAP_ASINSTANCES communicate with the presentation layer, the database layer, and with each other using the message server. The most important components of an ABAP_ASINSTANCE are its work processes, the number and type of which are determined when the AS ABAP is started. An ABAP program is executed by a suitable ABAP_ASINSTANCE work process.
The transaction SM51 shows an overview of the ABAP_ASINSTANCES of the current AS ABAP and on which host computers they are instantiated. The name of the current ABAP_ASINSTANCE can be determined in an ABAP Program using the method GET_INSTANCE_NAME of the system class CL_ABAP_SYST. This name has the form hostname_sysid_instnr . Here, hostname is the name of the host computer of the ABAP_ASINSTANCE , sysid is the name of the AS ABAP, and instnr is the instance number of the ABAP_ASINSTANCE . The network name of the host computer on which the current ABAP_ASINSTANCE is instantiated can be found in the system field sy-host.
Every ABAP_ASINSTANCE has access to the standard database of the AS ABAP. Every ABAP_ASINSTANCE has its own shared memory. The ABAP runtime framework uses the shared memory for programs, program data, and buffers (for example, during table buffering). ABAP programs can store shared objects and data clusters in the shared memory.



Latest notes:

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

ABAP_EXAMPLE_VX5
Gets the name of the current ABAP_ASINSTANCE .
ABEXA 01126
ABAP_EXAMPLE_END

User Session
Logging on to an ABAP_ASINSTANCE opens a user session. Logons take place using SAP GUI, the RFC interface, or ICF (including APC). A user session is assigned a separate memory area, the user memory, which can be used as follows in ABAP programs:
The user memory stores SPA/GPA parameters that can be accessed using the statements SET PARAMETER and GET PARAMETER.
The ABAP Daemon Memory is a subarea of the user memory in which ABAP daemons can store context information in PCP format.
The maximum number of user sessions is determined by the profile parameter rdisp/tm_max_no. The profile parameter rdisp/rfc_max_login determines which percentage of the sessions can be opened using the RFC interface.
For more information, see User Sessions.

ABAP Session
An ABAP session is opened for each user session. Each ABAP session is assigned its own memory area 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 remains. The SAP Easy Access program does not work as a top level transaction for the ABAP memory.
Additional ABAP sessions for a user session can be opened as follows:
Enter a transaction code after /o in the command field in the toolbar.
Call the function module TH_CREATE_MODE.
Call a dynpro during the processing of asynchronous RFC. In the RFC client, an additional ABAP session for communication with the SAP GUI is required.
A maximum of 16 ABAP sessions are possible per user session. The number of sessions that is actually possible for a system is determined by the profile parameter rdisp/max_alt_modes, whose default value is 16.



Latest notes:

NON_V5_HINTS
The ABAP memory can be used to transfer data between the programs in a call sequence .
For logging and analysis purposes, each ABAP session has an extended passport (EPP) that contains constant values and that can be passed on to communication partners, such as other ABAP sessions or external interfaces, whereby modifiable values are set for the respective connection.
ABAP_HINT_END

ABAP_ISESS_L
Each call of an ABAP program creates a new ABAP_ISESS , in which the called program is loaded.
An ABAP_ISESS contains a session memory that is divided into the areas heap and stack from the perspective of an ABAP program. The modifiable objects of the program live there. The non-modifiable data of the program is stored in the PXA. The session memory contains references to the required data in the PXA. From a technical perspective, the session memory and the global PXA are stored in the shared memory of the ABAP_ASINSTANCE where they managed by the SAP Memory Management.
In an ABAP session, there can be a maximum of nine ABAP_ISESSNS that always belong to a call sequence. Data from the ABAP memory is always assigned to a call sequence.
On 64-bit platforms, an ABAP_ISESS can theoretically require up to 4 TB of memory. 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.
Further information about the way ABAP programs are organized in an ABAP_ISESS can be found in Programs in the ABAP_ISESS_L .



Latest notes:

NON_V5_HINTS
The available session memory is defined using the profile parameters described under Session Memory . It is also possible to define a percentage of the available memory as a limit, over which a runtime warning occurs.
Instances of classes, except for shared objects, are located in the ABAP_ISESS . It is therefore not possible to store references to objects in the ABAP memory.
On 32-bit platforms, that are not supported any more, the theoretical upper limit for the memory that an ABAP_ISESS could require was 4GB.
Class CL_SESSION_INFO returns information about the current session.
ABAP_HINT_END

ABAP_EXAMPLE_VX5
Usage of CL_SESSION_INFO.
ABEXA 01505
ABAP_EXAMPLE_END