- General Memory Organization
- Programs in the Internal Session
1. 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 description with more technical details, see the SAP Memory Management of the
The following figure 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 ABAPs 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 AS ABAP database. 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 saving data explicitly from ABAP programs.
User Session
Logging on to an application server opens a user session. Logons take place using SAP GUI, the RFC interface, or ICF (including APC). A user session is assigned its own memory area of the user memory, in which SPA/GPA parameters can be stored. There are various types of user sessions and various rules apply when ABAP programs are executed:
- Dialog sessions
- Background sessions
- Update sessions
- RFC sessions
- ICF sessions
- APC sessions
From a user session, it is possible to open further user sessions on the same application server or another server in a program-driven way. For example:
- A remote function call with the destination "NONE" opens a user session on the same application server.
- Calls of update modules using COMMIT WORK or executions of executable programs in background programming open separate user sessions.
- ICF clients and APC clients can address the current application server or other servers as ICF servers or APC servers and hence open new user sessions.
The maximum number of user sessions is configured using 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.
ABAP Session
An ABAP session is opened for each user session. Each ABAP 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.
Further ABAP sessions for a user session can be opened as followed:
- Enter a transaction code after "/o" in the command field in the toolbar.
- Call the function module TH_CREATE_MODE.
- Call a dynpro when processing an asynchronous RFC. To do this, the RFC client requires an additional ABAP session for communication with SAP GUI.
A maximum of 16 ABAP sessions are possible per user session. The number of sessions actually possible for a system is determined by the profile 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 modifiable objects of the program are held. The non-modifiable program data 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 the responsibility of SAP Memory Management.
In one ABAP 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 consumers.
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.
2. Programs in the Internal Session
The following figure shows the memory organization within an internal session:
- Program Groups
In an internal session it is possible to load multiple programs that can be organized in program groups. Once an internal session is exited, it is closed. It is then no longer possible to access data and objects of the internal session.
- Main Program Group
When an internal session is created by calling an ABAP program using SUBMIT or a transaction code, the main program group is created and the called program is its main program. The full internal session exists for as long as the main program of the main program group is executed. This can be an executable program, a module pool, or a function group.
- Additional Program Group
Every time that a new class pool or a new function group is loaded by an external usage, an additional program group is created and the class pool or the function group is the main program of the additional program group. An external usage is usually an access to components exposed (visible components of the global class or function module) by the class pool or function group. However, it can also be an access to local components, such as in a type specification using absolute type names. An additional program group is persisted for as long as the internal session exists.
- Main Program of a Program Group
The first program loaded of a program group is the main program of this group. The main program of a main program group is the first program loaded into the internal session by a program call (executable program, module pool, or function group). The main program of an additional program group is a class pool or a function group whose loading results in the additional program group being created.
- Programs Loaded into a Program Group
When programs that are not function groups or class pools are loaded because they are used externally, they do not create additional program groups and are loaded into the program group of the consumer instead. This happens for example:
- during the external call of subroutines that are defined in executable programs, module pools or subroutine pools
- when using the dynpro statement CALL SUBSCREEN sub_area INCLUDING prog, if the dynpro is not defined in a function group
- during dynamic access to a local data type or object type of an executable program, module pool, or a subroutine using absolute type names
- with statements such as SET PF-STATUS OF PROGRAM, if the program of the necessary component is not a function group.
Notes
- It is not the program type that is important for the assignment of a program to a program group, but the introductory program statement. For example, if the statement FUNCTION-POOL is used in a subroutine pool instead of PROGRAM, when the program is loaded by an external usage it forms an additional program group.
- Since all the programs of a program group use the interface work area, the dynpros, lists, and GUI statuses of the main program (more below), the assignment of a program that is loaded into a program group is particularly important if procedures of this program are called externally.
- Data Objects
The data objects of a program, with the exception of the interface work area, belong exclusively to their program and are only visible there. A loaded program exists for the same length of time as the internal session. After returning from a program, its data objects are retained and are available if a procedure of the program is called again.
- Instances of Classes
Objects as instances of classes can be used by all programs (and objects) of an internal session. An object exists for as long as there are consumers for, and hence references to, the object.
Note: This means that references to objects of the internal session can be passed to externally called procedures.
- Interface Work Areas
Data objects declared with TABLES or DATA BEGIN|END OF COMMON PART ... are interface work areas. These are only created once per program group and are used by all programs of a program group together.
Note: The assignment of a program to a program group, and thus the determination of which other programs it shares the interface work area with, can depend on the order used.
- Dynpros, Lists, and GUI Statuses
Only the dynpros of the main program of a program group can be called using CALL SCREEN. After an internal session is loaded, these are the dynpros of the main program of the main program group. The main programs (function groups) of additional program groups can also call their own dynpros.
Lists are always assigned to the current dynpro sequence and therefore also to the main program of the program group.
As standard, SET PF-STATUS is used to access the GUI status of the main program of a program group and use its data objects for dynamic texts.
All programs of a program group work with the dynpros, lists, and GUI status of the main program by default. A statement CALL SCREEN in an externally called subroutine, for example, never calls a dynpro from its own master program. The dialog modules and list result blocks of the main program are executed
