
Die grundlegende Terminologie im Zusammenhang mit Speicherverwaltung wird hier vorausgesetzt. Eine Zusammenfassung der wichtigsten Begriffe finden Sie im Abschnitt Memory Management: Grundbegriffe.
Im Umfeld vom VM Container wird ausschließlich Shared Memory verwendet, um das SAP-Konzept von Roll-in und Roll-out (vgl. SAP-Transaktionen und VM Container) umsetzen zu können. Jeder Workprozess kann sich Teile dieser gemeinsamen Ressource in seinen Adressraum einblenden (adressstabil). Nur in Ausnahmefällen kann es kurzzeitig zur Allokation von prozesslokalem Speicher kommen.
Wenn also im folgenden von Heap (Java-Heap und VM-Heap) gesprochen wird, so ist nicht prozesslokaler Speicher gemeint.
Shared Memory
Das Shared Memory ist bei Verwendung von VM Container in folgende Bereiche unterteilt.

Neben dem Extended Memory (EM) für den ABAP-Kontext gibt es die Bereiche EM2 sowie EG2.
Im EM2 befinden sich die VM-lokalen Bereiche (VM-Heap und Java-Heap), im EG2 liegt der von allen VMs genutzte Bereich (Shared Pool). Im Gegensatz zum ABAP-EM, dessen Gesamtgröße mit dem Parameter em/initial_size_MB festgelegt wird, werden die Größen von EM2 und EG2 vom System berechnet und dynamisch angepasst. Sie legen lediglich die maximale Größe des Shared Pools und der Heaps fest.
Beachten Sie auf 32-Bit-Plattformen, dass der Adressraum auf ca. 2GB begrenzt ist. Sie sollten hier, falls Sie hauptsächlich VM Container und wenig ABAP verwenden, das ABAP-EM und den ABAP-PXA-Puffer (abap/buffersize) klein einstellen, um nicht an die Grenzen zu stoßen.
Speichertypen
Für VM Container gibt es folgende Speichertypen.
Java Heap: Auf dem Java-Heap werden die Java-Objekte einer VM abgelegt. Jede VM hat ihren eigenen Java-Heap, andere VMs haben keinen Zugriff darauf.
VM-Heap: Der VM-Heap dient zur Ablage lokaler Objekte sowie Java- und Service-Stacks der VM. Er kann nur von einer VM benutzt werden.
Shared Pool: der Shared Pool kann von allen VMs verwendet werden und beherbergt die gemeinsamen Java-Objekte (Shared Closures, Shared Classes, Shared Code Cache für kompilierten Code etc.
Folgende Grafik veranschaulicht die Speicherbereiche und zeigt den Zusammenhang mit den wichtigsten Speicherparametern.

Die Gesamtgröße des Shared Pools wird mit dem Parameter vmcj/option/ps festgelegt. Der Teil des Shared Pools, der für den kompilierten Code des JIT-Compilers reserviert ist, kann als einziger explizit mit dem Parameter vmcj/option /sharedCodeCache gesetzt werden.
Für die VM-lokalen Heaps gibt es folgende Parameter:
vmcj/ max_vm_heap_MB legt die maximale Größe für den VM-Heap fest, der die lokalen Klassen, den lokalen Code Cache sowie den Java- und den Service-Stack beinhaltet
vmcj/option/maxJavaHeap legt die maximale Größe des Java Heaps fest.
Garbage Collection
Sowohl auf dem VM-lokalen Java Heap als auch im gemeinsam genutzten Shared Pool wird periodisch eine Garbage Collection durchgeführt.
Weiter Informationen dazu finden Sie in den folgenden Abschnitten:
Java-Heap: Funktionsweise des Local Garbage Collectors
Shared Pool: Funktionsweise des Shared Garbage Collectors