{"id":41519,"date":"2024-11-27T10:42:44","date_gmt":"2024-11-27T09:42:44","guid":{"rendered":"https:\/\/www.happycoders.eu\/?p=41519"},"modified":"2025-06-12T08:36:41","modified_gmt":"2025-06-12T06:36:41","slug":"compressed-oops","status":"publish","type":"post","link":"https:\/\/www.happycoders.eu\/de\/java\/compressed-oops\/","title":{"rendered":"Compressed Oops in Java"},"content":{"rendered":"\n

In diesem Artikel erf\u00e4hrst du wie durch \"Compressed Oops\" auf einem 64-Bit-System Referenzen auf Java-Objekte mit nur 32 statt 64 Bits dargestellt werden k\u00f6nnen und wie dadurch der Speicherbedarf einer Java-Anwendung signifikant reduziert wird.<\/p>\n\n\n\n

Was ist ein 64-Bit-System?<\/h2>\n\n\n\n

Ein 64-Bit-System zeichnet sich dadurch aus, dass Pointer auf Adressen im Arbeitsspeicher 64 Bit gro\u00df sind. Dadurch lassen sich 264<\/sup> Bytes = 16 Exabyte = 18.446.744.073.709.551.616 Bytes adressieren.<\/p>\n\n\n\n

Heutzutage gibt es praktisch keine Programme mit diesem Speicherbedarf. In zehn Jahren werden wir \u00fcber diese Aussage vielleicht schmunzeln ;-)<\/p>\n\n\n\n

Hier die grafische Darstellung eines solchen 64-Bit-Pointers:<\/p>\n\n\n

\n
\"64-Bit-Pointer\"<\/figure>\n<\/div>\n\n\n

Nun k\u00f6nnte man \u00fcberlegen, diese 64 Bit in der Mitte zu teilen und mit der gleichen Speichermenge nicht nur einen, sondern zwei Pointer zu speichern:<\/p>\n\n\n

\n
\"Zwei<\/figure>\n<\/div>\n\n\n

Mit 32 Bit lassen sich allerdings nur 232<\/sup> Bytes = 4 GB adressieren. Das wiederum ist f\u00fcr viele Anwendungen zu wenig.<\/p>\n\n\n\n

Die Java-Entwickler haben sich daher einen cleveren Trick (\u201eCompressed Oops\u201c) einfallen lassen, um mit 32 Bit nicht nur 4 GB sondern 32 GB zu adressieren. Und das wiederum ist f\u00fcr die meisten Anwendungen unserer Zeit ausreichend.<\/p>\n\n\n\n

Wie funktionieren Compressed Oops?<\/h2>\n\n\n\n

Durch Compressed Oops (OOP steht f\u00fcr \u201eordinary object pointer\u201c) kann mit 32-Bit-Pointern ein Adressraum von 235<\/sup> = 32 Gigabyte adressiert werden.<\/p>\n\n\n\n

Wie ist das m\u00f6glich? Um 32 Gigabyte zu adressieren, br\u00e4uchten wir doch eigentlich 35 Bits. 35 Bits k\u00f6nnen wir aber nicht in einem 32-Bit-int speichern, daf\u00fcr br\u00e4uchten wir die n\u00e4chstgr\u00f6\u00dfere Datenstruktur, ein 64-Bit-long:<\/p>\n\n\n

\n
\"35-Bit-Pointer\"<\/figure>\n<\/div>\n\n\n

Wir h\u00e4tten also 29 Bit verschwendet. Dann h\u00e4tten wir auch bei 64-Bit-Pointern bleiben k\u00f6nnen.<\/p>\n\n\n\n

Es wird Zeit einen Trick anzuwenden!<\/p>\n\n\n\n

Zun\u00e4chst einmal positionieren wir alle Java-Objekte an durch acht teilbare Speicheradressen. Acht ist 23<\/sup>, d. h. die letzten 3 Bits eines Pointers sind immer 0. Somit enthalten also nur die oberen 32 Bit relevante Informationen:<\/p>\n\n\n

\n
\"32<\/figure>\n<\/div>\n\n\n

Da wir wissen, dass die letzten drei Bits immer 0 sind, brauchen wir diese nicht jedes Mal mit abzuspeichern. Die 35-Bit-Speicheradresse kann daher ohne Informationsverlust um 3 Bit nach rechts verschoben und somit in einem 32-Bit-Feld gespeichert werden:<\/p>\n\n\n

\n
\"Compressed<\/figure>\n<\/div>\n\n\n

Um sp\u00e4ter wieder auf die unkomprimierte Speicheradresse zugreifen zu k\u00f6nnen, m\u00fcssen die 32 Bit lediglich wieder um 3 Bit nach links geschoben werden.<\/p>\n\n\n\n

Compressed Oops sind standardm\u00e4\u00dfig aktiviert<\/h2>\n\n\n\n

Auf einem 64-Bit-System mit maximal 32 GB Heap sind Compressed OOPs standardm\u00e4\u00dfig aktiviert. Bei mehr als 32 GB k\u00f6nnen Compressed Oops nicht verwendet werden, da sie eben nur 32 GB adressieren k\u00f6nnen.<\/p>\n\n\n\n

Compressed Oops k\u00f6nnen mit folgender VM-Option deaktiviert werden:<\/p>\n\n\n\n

-XX:-UseCompressedOops<\/code><\/p>\n\n\n\n

Warum sollte man das tun?<\/p>\n\n\n\n

Das Komprimieren und Dekomprimieren der Pointer kostet Zeit. Nicht viel, da die daf\u00fcr ben\u00f6tigte Shift-Operation in der Regel in einem einzigen CPU-Zyklus durchgef\u00fchrt werden kann. Doch wer das letzte Qu\u00e4nt\u00adchen Performance aus seiner Anwendung herauskitzeln will und den daf\u00fcr erh\u00f6hten Speicherbedarf in Kauf nehmen will (alle Pointer belegen 64 statt 32 Bits), der kann diese M\u00f6glichkeit in Betracht ziehen.<\/p>\n\n\n\n

<\/path><\/svg><\/div>
<\/div>

Bis Java 14 war die Aktivierung von Compressed Class Pointers<\/a> an die Aktivierung von Compressed OOPs gekoppelt. Wenn man Compressed OOPs deaktivierte, wurden automatisch auch Compressed Class Pointers deaktiviert. Da es keinen Grund f\u00fcr diese Kopplung gab, wurde sie in Java 15<\/a> aufgehoben.<\/p><\/div><\/div>\n\n\n\n

Fazit<\/h2>\n\n\n\n

Mit Compressed Oops lassen sich auf einem 64-Bit-System mit einer Heapgr\u00f6\u00dfe von maximal 32 GB Speicheradressen mit nur 32 statt 64 Bits kodieren. Das es auf jedes aktive Java-Objekt in einer Anwendung mindestens einen Pointer gibt, kann somit der Speicherbedarf einer Anwendung signifikant reduziert werden.<\/p>\n