ABAP Compiler and Runtime Objects

Development objects are stored in the Repository in the form in which they are developed. These are the only versions of the development objects that can be displayed in the Workbench.

 

To run a program in the ABAP runtime environment, the program must first be generated, using the ABAP Compiler.

 

 

Inactive Sources

When you change an active development object and save it, the system creates an inactive version, in addition to the existing active version.

 

Saving an inactive version has no effect on the program LOAD. Accordingly, the syntax of the inactive version does not necessarily have to be correct. You can also save an interim, non-executable version of the development object inactively. However, the active version remains available as an executable version.

 

You can toggle the view between the active and inactive versions, but you can only edit the inactive version. When a syntax check is performed, it is done on the version in development (the inactive version), but not on the generated version. When running source code for executable programs from the ABAP Editor, the system refers back to the inactive version. In this case, the system creates a temporary generated version that is not buffered or stored in the database. In all other cases, the system always accesses the active version when you execute the program.  ​

 

 

Program Activation

All inactive objects that the system assigns to your user ID are listed in your work list.

The following steps occur when you activate an object:

1. The object is saved, that is, a new inactive version is created. This is subject to a syntax check.
2. The system overwrites the current active version. The previously inactive version is now the active version, which means there is no longer an inactive version.
3. The system creates a new runtime version and updates the LOAD.

 

Program Execution Area (PXA) and Roll A

When the runtime system generates a new runtime object (the LOAD) of a program or loads it from the database, it places the program in the working memory of the application server. In the process, the runtime system treats the modifiable parts of the program differently than the non-modifiable parts.

 

The system stores the non-modifiable parts of the program in the PXA and buffers them there as long as possible. This memory area is shared by all users on the application server and exists only once on each server. After a program is executed, the byte code of the program remains buffered in the PXA for as long as possible. Buffering prevents the system from loading the code from the database again during the next execution.

 

The modifiable parts of the program are created in memory during every execution, in a memory space called the roll area. When the program is executed several times concurrently (by the same user or different users), each execution has its own roll area. This ensures that the system executes the programs independently of one another.

 

 

Memory Management from the Program Perspective

 

Program Groups

When a program calls external modularization units, the system loads the corresponding programs into the same internal session. The programs within an internal session form program groups. When the system opens an internal session with a program call, the system always creates the main program group. There can be one or more additional program groups. Each program group contains one main program, and possibly other programs as well.

 

The program data objects are only visible within its program group, which means programs in different program groups do not share any data objects. All programs and objects of an internal session can use instances of classes. An object continues to exist as long as there are references to it.

 

 

Memory Management for Program Calls