Warum in die Ferne schweifen...

JEP 383: Foreign-Memory Access API (Second Incubator)
Keine Kommentare

Der Zugriff auf fremden Speicher ist in Java-Anwendungen und den verwendeten Bibliotheken an der Tagesordnung. Das Foreign-Memory Access API soll diese Aktion in Zukunft deutlich erleichtern. Für Java 15 wurde zudem das neue VarHandle combinator API implementiert. Wir haben uns JEP 383 einmal genauer angesehen…

Es gibt tonnenweise Java-Bibliotheken und auch -Anwendungen, die auf fremden Speicher zugreifen. Prominente Beispiele sind Ignite, mapDB, memchaced oder Nettys ByteBuf API. Dennoch stellt das Java API selbst keine gute Möglichkeit hierfür zur Verfügung – und das obwohl dadurch Kosten in Sachen Garbage Collection (besonders bei der Verwaltung großen Caches) gespart und Speicher über mehrere Prozesse hinweg geteilt werden kann. Auch das Serialisieren und Deserialisieren von Speicherinhalten via Mappings von Dateien in den Speichern wird durch den Zugriff auf fremden Speicher möglich (etwa via mmap).

Mit JEP 370 wurde ein passendes Java API ins JDK implementiert, mit dem Java-Anwendungen sicher und effizient auf fremden Speicher zugreifen lässt, der außerhalb des Java Heaps angesiedelt ist. Wichtig sind die drei Prämissen: Allgemeingültigkeit, Sicherheit und Determinismus. JEP 383 stellt die zweite Inkubatorphase des im Projekt Panama entwickelten APIs dar.

In diesem Zusammenhang bedeutet „Allgemeingültigkeit“, dass ein einziges API in Verbindung mit unterschiedlichen fremden Speichern arbeiten sollte (gemeint sind nativer Speicher, persistenter Speicher etc.). Die „Sicherheit“ der JVM ist das höchste Gut, daher sollte das API nicht dazu fähig sein, diese zu unterwandern – völlig egal, welcher Speicher zum Einsatz kommt. Zudem („Determinismus“) sollte die Freigabe von Speicher explizit im Quelltext erfolgen.

Für den Rehaul in Java 15 wurde das neue VarHandle combinator API implementiert, das die Individualisierbarkeit der var-Handles für den Speicherzugriff gewährleistet. Die Unterstützung für das Parallel Processing einzelner Speichersegmente via Spliterator-Interface ist ebenso Teil der Überarbeitung wie ein verbesserter Support für „gemappte“ Speichersegmente (bspw. MappedMemorySegment::force). Neu sind auch sichere API-Punkte, um serielle Einschränkungen zu unterstützen, und unsichere API-Punkte. Letztere erlauben das Manipulieren und Rückverweisen von Adressen, die etwa von nativen Aufrufen stammen. Durch unsichere API-Punkte können zudem solcherlei Adressen in synthetische Speichersegmente gewrappt werden.

JEP 383 wurde im Zuge des Project Panama entwickelt und stellt eine klare Alternative zur Verwendung von existierenden APIs wie ByteBuffer, Unsafe oder JNI dar. Natürlich hilft die Implementierung bei der Erreichung der generellen Maxime des Projektes: der Unterstützung von nativer Interoperabilität von Java.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Abonnieren
Benachrichtige mich bei
guest
0 Comments
Inline Feedbacks
View all comments
X
- Gib Deinen Standort ein -
- or -