Suche
Interview mit Christoph Engelbert

„Warum sollte Oracle in der Lage sein, schnelleren Java-Code zu schreiben als ich?“

Redaktion JAXenter

© Shutterstock.com/Fernando Sanchez Cortes

Die Pläne, das sun.misc.Unsafe API aus Java 9 zu entfernen, werden in der Community heiß diskutiert. Wir haben Christoph Engelbert (Hazelcast) nach seiner Einschätzung gefragt: Worin liegen die Probleme, wie könnte eine Lösung aussehen?

JAXenter: Es scheint Pläne zu geben, das sun.misc.Unsafe API vom JDK 9 zu entfernen. Was ist der Grund dafür?

Christoph Engelbert: Die Gründe dafür sind recht einfach. Zum einen gibt es da den Wunsch, das JDK selbst im Rahmen des Projekt Jigsaw in Module aufzusplitten. Ein anderer offensichtlicher Grund ist die Sicherheit. Da nicht alle Module installiert werden müssen, sinkt auf bestimmten Computern das Risiko für Sicherheitsprobleme.

Um das zu unterstützen, führt Jigsaw eine neue Form von Sichtbarkeit ein. Neben private, package private und public gibt es module. Das bedeutet, dass die Modul-Metadaten definieren, welche Packages tatsächlich vom Modul exportiert werden – eine Idee, die stark an OSGi erinnert. Außerdem wird beabsichtigt, die Packages zu säubern, die nicht dafür gedacht waren, für den User sichtbar zu sein.

Nichtsdestotrotz verschwindet sun.misc.Unsafe nicht wirklich, es ist nur für den User versteckt. Die JDK/JRE Internals sind nach wie vor in der Lage, Unsafe zu nutzen.

JAXenter: Es gibt eine ziemlich kontroverse Debatte darum. Worin liegt das Problem beim Entfernen von sun.misc.Unsafe?

Engelbert: Das größte Problem ist, dass es so lange verfügbar war. Die Leute haben es für alle möglichen Lösungen genutzt. Es gab Fälle, in denen AtomicX-Klassen das Problem gelöst hätten, aber die Leute haben dennoch Unsafe benutzt, vielleicht weil es cool war. Oder man benutzte es, um in ein Array zu schreiben, was mit Unsafe zwar nicht essentiell notwendig, aber etwas schneller ist. Und dann hatte man die Use Cases, wo sun.misc.Unsafe die einzig mögliche Lösung war.

Eine dieser letztgenannten Use Cases ist die Interaktion mit nativem Code. Ein einfaches Beispiel ist ein kleines Projekt, welches ich geschrieben habe, das einen Java Wrapper um die libbz2 Library implementiert. Der C-Code verwendet native Zeiger, um Speicher zu beschreiben und auszulesen, dabei hat man nur Speicher-Adressen. Es ist einfach nicht möglich, in Java ohne sun.misc.Unsafe direkt auf den Speicher zuzugreifen.

Ein weiterer Grund für die Nutzung von Unsafe ist die Performance. Fast alle Methoden sind intrinsisch, was bedeutet, dass die tatsächlichen nativen Aufrufe nie wirklich ausgeführt werden, sondern eine spezielle Sequenz von Assembler Code direkt in den jitted Java-Code injiziert wird. Das ist unbedingt notwendig, wenn man im Niedriglatenzbereich arbeitet.

Es gibt viele weitere Use Cases, aber es würde zu lange dauern, alle zu nennen – nur als kurzer Überblick: schnelle Deserialisierung, Mocking Frameworks, Java Object Layout Analyse, Network Libraries usw.

JAXenter: Was würde das Entfernen von sun.misc.Unsafe für Hazelcast und seine Kunden bedeuten?

Engelbert: Das hängt stark davon ab, wie der Migrationsweg aussehen wird, den Oracle anbieten wird. Im Moment ist der Plan, ein Command Line Flag anzubieten, um das versteckte sun.misc Package wieder zurückzuholen. Wie dieser Flag genau aussehen wird, ist noch nicht ganz klar, aber er wird die Möglichkeit bieten, sun.misc.Unsafe in Java 9 zu verwenden.

Hazelcast Enterprise nutzt sun.misc.Unsafe für die HD-Memory-Implementierung, um große Datenmengen im Java Process Memory Space zu speichern. Wir werden höchstwahrscheinlich die HD Storage Engine re-implementieren müssen, um ein mögliches Ersatz-API zu verwenden.

Das bedeutet, dass jeder unserer Enterprise-Kunden, der HD Memory verwendet, Probleme mit Java 9 haben wird, zumindest am Anfang. Wir werden die Leute daran erinnern, das Command Line Flag für Java 9 zu setzen, sobald es bekannt gegeben wird.

Doch das wahre Problem, das ich hier sehe, ist, dass die Leute einen neuen und unbekannten Parameter in ihre JVM Startup-Konfiguration hinzufügen müssen. Die meisten Leute wissen wahrscheinlich noch nicht einmal, dass sie Unsafe benutzen, weil es eine transiente Abhängigkeit von einer oder mehreren Libraries ist, die sich irgendwo in ihren Applikationen versteckt. Wenn man einen Blick in das Dokument „What to do about sun.misc.Unsafe?“ wirft, das schon seit einigen Tagen im Umlauf ist, wird man sehen, wie viele große und oft verwendete Frameworks in irgendeiner Art auf Unsafe basieren.

Das bedeutet für mich: Entweder wird dieser Parameter nicht gesetzt, sodass Applikationen nicht mehr starten oder langsamer werden. Oder er wird zu einer Art De-facto Standard.

Aber damit ist das Problem noch nicht erschöpft. Auch wenn Libraries Fallbacks anbieten, für den Fall, dass sun.misc.Unsafe nicht verfügbar ist, sind diese oft nicht so umfassend getestet wie der Unsafe-Code-Path. Der Grund dafür ist einfach, es gab schlicht keine Notwendigkeit dafür. User könnten also Probleme bekommen, die sie vorher nie hatten.

JAXenter: Warum besteht die Lösung nicht einfach darin, die Libraries, die von sun.misc.Unsafe Gebrauch machen, auf die offiziell unterstützten APIs upzudaten?

Engelbert: User könnten Libraries verwenden, die nicht mehr aktiv entwickelt werden. Für meine oben erwähnte Beispiel-Library (libbvz Wrapper) gibt es schon seit langem keine aktive Entwicklung mehr, da sie einfach schon „Feature complete“ ist. Wenn ich nun ein Update machen würde, könnten andere Libraries schon eingestellt worden sein.

Solange eine Library oder Applikation Open Source ist, gibt es eine hohe Wahrscheinlichkeit, dass sich jemand der Entwicklung annehmen und eine neue Version erstellen wird. Es sind aber zahlreiche bezahlte Libraries in Gebrauch, bei denen das Unternehmen, welches sie ursprünglich entwickelt hat, gar nicht mehr existiert. Niemand ist in der Lage, diese Libraries upzudaten. Einen Ersatz für sie zu kaufen, ist ein Investment für die Firma, die sie benutzt hat.

Diese Firmen werden höchstwahrscheinlich bei Java 8 bleiben.

JAXenter: Hazelcast hat einige Lösungen in dem genannten öffentlichen Google Doc präsentiert. Kannst du eure Ideen kurz zusammenfassen?

Engelbert: Das Google Doc macht noch keine Lösungsvorschläge. Es ist lediglich eine Sammlung unserer Erkenntnisse. Es macht die Menge der Libraries sichtbar und zeigt, dass fast jede größere Applikation auf dem Markt betroffen ist. Wir haben eine Arbeitsgruppe angestoßen, um an Ideen für einen geräuschloseren Migrationsweg zu arbeiten und auch um Alternativen für sun.misc.Unsafe zu finden. Während die Arbeitsgruppe sich noch in einem sehr frühen Stadium befindet, habe ich angefangen, mit Paul Sandoz an seinem VarHandle-Vorschlag zu arbeiten, um fehlende Use Cases und Probleme in dem API zu finden. Ich schaue mir außerdem erste Performance Benchmarks an, um sicherzustellen, dass die Performance-Werte stimmen. Allerdings sind VarHandles nur ein Ersatz für ein Subset von sun.misc.Unsafe.

JAXenter: Wer unterstützt eure Position?

Engelbert: Betrachtet man das Google Doc, sieht man eine große Bandbreite verschiedener Unternehmen – Banken, JVM-Entwickler bis hin zu Java User Groups wie SouJava. Zudem gibt es viele Industrie-bekannte Personen wie Peter Lawrey oder Martijn Verburg. Außerdem unterstützen einige Java-Champions, welche nicht direkt am Google Doc oder in der Arbeitsgruppe mitarbeiten, unsere Position, beispielsweise Kirk Pepperdine.

Da sun.misc.Unsafe das Schweizer Taschenmesser für Performance-Dinge in Java ist, ist es weitverbreitet – ein ganzer Zweig des Java-Ökosystems hängt davon ab. Deswegen mussten wir aktiv werden. Peter Lawrey und ich haben schon letztes Jahr versucht, auf das Problem aufmerksam zu machen, doch ohne Erfolg. Nun bekommt das Problem endlich die Aufmerksamkeit, die es verdient.

JAXenter: Was denkst du, wird ein mögliches Ergebnis sein? Werdet ihr in der Lage sein, Oracle zu überzeugen eine andere Lösung zu finden, als sun.msic.Unsafe einfach nur zu entfernen?

Engelbert: Ich glaube nicht, dass wir das tun möchten. Ich habe hier möglicherweise eine andere Meinung als viele andere, aber das Unsafe API ist hässlich, klobig und… habe ich schon hässlich gesagt? Schon bevor Oracle den Plan bekannt gab, das API zu entfernen, habe ich mich für sauberes und offiziell unterstütztes Ersatz-API ausgesprochen. Unsafe sollte „verschwinden“, aber bitte behaltet den Command Line Flag für Leute mit alten Libraries.

Was wir auf jeden Fall sicherstellen müssen, ist, dass wir für aktuelle Use Cases Alternativen bereit stellen, die schnell sind und die Probleme sauber lösen. Wenn ich auf die Oracle-Umfrage im letzten Jahr zurückblicke, waren die meisten sun.misc.Unsafe-User darauf vorbereitet, ihre Anwendungslogik basierend auf einem Ersatz für Unsafe zu re-implementieren. Der Prozentsatz der Neinsager war sehr gering, und es ist fraglich, ob diese etwas anderes tun würden, egal wie die Lösung aussehen wird.

Ich möchte mit einer Tatsache abschließen, die sich für mich persönlich etwas merkwürdig anfühlt. Vor einigen Tagen war da ein Twitter-Post, der sagte „Framework developers just don’t like to be put in the position of users“. Abgesehen davon, dass dieser Satz stimmen könnte, frage ich mich, warum Oracle in der Lage sein sollte, schnelleren Java-Code zu schreiben als ich selbst. Für mich klingt das wie eine sehr falsche Idee. Und betrachtet man andere VM-Sprachen wie .NET oder Python oder was auch immer, stellt man fest, dass fast alle eine Definition von einer „Unsafe Section“ haben, in der direkte Speicherzugriffe möglich sind. Ich denke, aus gutem Grund. Wenn wir nie sun.misc.Unsafe gehabt hätten, wer weiß, wo Java heute wäre. Höchstwahrscheinlich jedenfalls nicht im Bereich des Hochfrequemnzhandels.

Christoph Engelbert is the Technical Evangelist and Senior Solutions Architect at Hazelcast. He’s also an Apache Committer and Open Source enthusiast, and is mostly interested in Performance Optimizations and understanding the internals of the JVM and the Garbage Collector.

 Aufmacherbild: Birthday-anniversary cake with red candles showing Nr. 9 von Shutterstock.com / Urheberrecht: Fernando Sanchez Cortes

Verwandte Themen:

Geschrieben von
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.