GraalVM ist eine erweiterte Java-VM, die neben Java noch diverse andere Sprachen unterstützt. Diese bietet einer bisher unerreichte Interoperabilität. So ist es beispielsweise möglich, von Java aus direkt auf Datenstrukturen oder Funktionen von Python oder JavaScript zuzugreifen.
Neu ist jetzt eine experimentelle Unterstützung für WebAssembly (WASM). WASM ist ein standardisierter Bytecode, der speziell für Browser entworfen wurde. Dieser soll es ermöglichen, dass neben JavaScript noch andere Programmiersprachen für Web-Client-Programmierung genutzt werden können, in dem diese zu WASM-Bytecode kompiliert werden. Dieser Bytecode kann jetzt auch von der GraalVM ausgeführt werden.
Damit kann nun jede Sprache, für die es WASM-Compiler gibt, auch innerhalb der GraalVM genutzt werden.
Wer sich das genauer anschauen möchte, sollte einen Blick in die offizielle Ankündigung werfen.
Neben Java bzw JVM-Bytecode unterstützt GraalVM auch die Ausführung von LLVM-Bitcode.
$ cat > test.c
#include <stdio.h>
int main(void) {
printf("Hello World!\n");
return 0;
}
$ clang -c -emit-llvm test.c
$ $GRAALVM/bin/lli test.bc
Hello World!
Schon mal interessant, lustig wird es aber erst, wenn man dies mit Java kombiniert. Mit der Polyglot-API kann die Bitcode-Datei geladen, und einzelne Funktionen daraus ausgeführt werden.
import org.graalvm.polyglot.*;
import java.io.*;
public class HelloPolyglot {
public static void main(String[] args) {
try {
// create a polyglot context that can access the native interface
Context ctx = Context.newBuilder().allowAllAccess(true).build();
// load an llvm bitcode file
File file = new File("test.bc");
Source source = Source.newBuilder("llvm", file).build();
Value c = ctx.eval(source);
// get the main function and execute it
c.getMember("main").execute();
} catch (IOException e) {
System.err.println(e);
}
}
}
Ich hab auch ein etwas größeres Beispielprogramm.
Links:
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).
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
Kommentare
Rudi | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
Peter | Artikel: XNEdit - Mein NEdit-Fork mit Unicode-Support
Damit wird Nedit durch XNedit ersetzt.
Danke!
Olaf | Artikel: XNEdit - Mein NEdit-Fork mit Unicode-Support
Anti-Aliasing hängt von der Schriftart ab. Mit einem bitmap font sollte die Schrift klassisch wie in nedit aussehen.
Einfach unter Preferences -> Default Settings -> Text Fonts nach einer passenden Schriftart suchen.
Peter | Artikel: XNEdit - Mein NEdit-Fork mit Unicode-Support
Mettigel | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
Ich hatte gedacht, dass der GX-415 im s920 deutlich mehr Dampf hat als der Raspi4.
Mein Thinclient verbraucht mit 16 GB RAM ~11 W idle, das ist das Dreifache vom RP4. Das muss man dem kleinen echt lassen... Sparsam ist er.
Olaf | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
Ergebnisse von der Ultra 80 wären natürlich interessant, insbesondere im Vergleich mit dem rpi1.
kosta | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
ich hätt hier zugriff auf Ultra-80 4CPU 4GB 2x Elite3D.
RO | Artikel: Benutzt bitte nur noch Unicode!
Sehe ich genauso.