UNIXwork

GraalVM kann aus Java-Bytecode ein natives Image, also nativen Maschinencode, erstellen. Damit erhält man ein normales Executable, das keine Abhängigkeit zur JVM hat, deutlich schneller startet und einen geringeren Ressourcenverbrauch hat.

Zum Test erstellen wir fix ein einfaches Java Hello World.

Hello.java

public class Hello {
	public static void main(String[] args) {
		System.out.println("Hello World!");
	}
}

Manifest.txt

Manifest-version: 1.0
Main-Class: Hello

Java-Code kompilieren und jar erstellen:

$ javac Hello.java
$ jar cfm Hello.jar Manifest.txt Hello.java
$ java -jar Hello.jar
Hello World!

Das native Image kann mit dem GraalVM-Tool native-image erstellt werden:

$ native-image -jar Hello.jar
Build on Server(pid: 8912, port: 26682)
   classlist:     350.53 ms
	   (cap):     605.69 ms
	   setup:     856.57 ms
  (typeflow):   4,224.92 ms
   (objects):   1,103.80 ms
  (features):      29.86 ms
	analysis:   5,452.54 ms
	universe:     195.50 ms
	 (parse):     917.86 ms
	(inline):     783.22 ms
   (compile):   5,169.52 ms
	 compile:   7,097.16 ms
	   image:     437.47 ms
	   write:     115.94 ms
	 [total]:  14,536.87 ms
$ ./Hello
Hello World

Die erzeugte Executable ist mit 5,4 Mb nicht gerade klein, enthält aber auch alle verwendeten Teile der Java Runtime schon precompiled.

Die schlechte Nachricht ist, dass dies nicht mit allem funktioniert. Einige Klassen können offenbar nicht kompiliert werden. Bei meinem Versuch ein einfaches Swing-Beispiel zu kompilieren, wurde ich darauf hingewiesen, dass sun.misc.URLClassPath$JarLoader unsupported ist:

Build on Server(pid: 9251, port: 26682)*
   classlist:   1,526.88 ms
	   (cap):     990.22 ms
	   setup:   2,164.54 ms
	analysis:  19,376.53 ms
error: unsupported features in 3 methods
Detailed message:
Error: Must not have a started Thread in the image heap.
Trace: 	object sun.java2d.opengl.OGLRenderQueue
	field sun.java2d.opengl.OGLRenderQueue.theInstance
Error: Unsupported type sun.misc.URLClassPath$JarLoader is reachable
...

Ergibt ja auch Sinn, dass ein JarLoader nicht mit reinem nativen Code ohne JVM funktioniert. Wer also hofft seine lieblings IDE, die dank Java fett und träge ist, zu einem schnellen nativen Kompilat umzuwandeln, der wird leider enttäuscht (und wehe mir sagt jemand, dass Visual Studio oder XCode gar nicht Java verwenden).

Oracle hat kürzlich die Solaris 11.4 Beta geupdated. Dies bringt nicht nur Fehlerbereinigungen, sondern auch ein paar interessante neue Features:

ZFS Device Removal

Bisher konnte man ein ZFS vdev nicht entfernen. Da die Daten auf alle vdevs verteilt werden, müsste ein großer Teil des Pools neugebaut werden. Dies wird jetzt allerdings unterstützt.

Was jedoch nicht geht ist aus einem raidz ein Device zu entfernen.

Scheduled Scrub

Bei einem ZFS Scrub werden alle Blöcke überprüft und gegebenfalls repariert. Dies sollte regelmäßig durchgeführt werden, jedoch musste ein zpool scrub bisher manuell aufgelöst werden. Neu ist jetzt, dass dies auch automatisch erledigt werden kann, was auch standardmäßig aktiviert ist.

Über die neue ZFS Property scrubinterval kann eingestellt werden, in welchen Abständen ein automatisches Scrubbing durchgeführt werden soll. Der Default-Wert sind 30 Tage.

Des Weiteren gibt es natürlich aktualisierte und neue Software.

Downloads gibt es hier, eine bereits bestehende Installation der Beta kann auch einfach mit pkg update aktualisiert werden.

Sprachen die innerhalb einer virtuellen Maschine laufen gibt es viele, wie beispielsweise Java, Python oder JavaScript. Dabei hat jede Sprache meistens ihre eigene VM, die speziell für ihre Sprache entworfen wurde. Andere Sprachen laufen dann entweder gar nicht in dieser VM, oder mit geringer Performance.

Nach jahrelanger Entwicklungsarbeit hat Oracle nun GraalVM vorgestellt, eine universale VM, die nicht speziell für eine Zielsprache designed ist, sondern unterschiedliche Programmiersprachen gleich gut mit ähnlicher Performance unterstützt. Dabei sind zur Laufzeit die Datenstrukturen der Sprachen auch kompatibel, wodurch es ohne Overhead möglich ist, Funktionen einer anderen Sprache aufzurufen.

Aktuell unterstützt werden JVM basierte Sprachen sowie JavaScript und LLVM-Bitcode. Bisher nur experimentell werden außerdem Ruby, R und Python unterstützt. Damit ist es also problemlos möglich, Rust oder C++-Code, der zu LLVM-Bitcode kompiliert wurde, mit Java oder JavaScript zu mischen. Die völlige Wahlfreiheit der Programmiersprache, ohne dabei durch Performance oder Verfügbarkeit von Bibliotheken beschränkt zu sein, ist tatsächlich ein interessantes Versprechen.

Auch interessant ist die Möglichkeit, Java-Anwendungen zu einem nativen Image zu kompilieren, was die Startzeit drastisch verkürzt und den Speicherverbrauch senkt.

Technisch gesehen setzt GraalVM auf einer normalen JVM auf, mit einem komplett neuen JIT-Compiler und APIs, über die neue Sprachen wie JavaScript in GraalVM eingebunden werden können. Oracle hat dabei die Hoffnung, dass Third-Party-Entwickler ihre Programmiersprachen für GraalVM adaptieren. Ich kann mir jedoch vorstellen, dass viele beim Thema Java bzw JVM erstmal skeptisch sind, ganz unabhängig von Oracle und irgendwelchen juristischen Fragen. Die JVM gilt nicht als besonders schlank, die Startzeiten von Java-Anwendungen sind zu lang und der Speicherverbrauch ist hoch. Auf dem Desktop gibt es kaum noch Java-Anwendungen, bis auf die paar Entwicklungsumgebungen.

GraalVM Webseite Download Beispiele

• C ist jetzt deprecated in gcc
• OpenBSD entfernt IPv4
• Linux wird von C nach C++ portiert
• UTF-128 standardisiert. Praktisch für IPv6-Adressen

Obwohl es schon mehrfach tot gesagt wurde und Oracle 150% aller Mitarbeiter entlassen hat, haben sie es doch geschafft, eine Beta von Solaris 11.4 zu veröffentlichen.

Es gibt ein paar neue interessante Features wie z.B. Sandboxes. Außerdem wurde auch der Desktop erneuert und Solaris kommt jetzt mit Gnome 3.24.

Es gibt also doch noch Lebenszeichen und Leute die an Solaris arbeiten.