Vi skaber exe-programmer fra Java med GraalVM - og det kører forrygende hurtigt

Oracle, der står bag Java-platformen, i hvert fald så vidt som at firmaet ejer varemærket, arbejder på en ny afviklingsplatform, med det pompøse navn GraalVM.

Det er en ny just-in-time compiler til JVM-verdenen, som fokuserer på ydelse og understøttelse af flere sprog. Twitter er blandt kunderne, men det firma bygger dog selv miljøet fra open source-kildekoden.

Udover Java kan Graal også klare sprog som Javascript, Ruby, Python og R. Graal kan også kompilere Java-kode ‘ahead-of-time’, hvor slutproduktet er eksekverbare filer, i stedet for Java-bytecode.

Oracle har flere gange nævnt i offentligheden, at det kan give hurtigere Java-programmer, men har til gengæld været lidt fåmælt på journalisters spørgsmål om, hvad der betinger den hurtigere programudførsel.

Derfor har vi spurgt Oracles hovedkvarter om, hvilke slags Java-programmer, der kan blive hurtigere.

»Der er for mange variable i programkonstruktion til at forudsige, hvornår GraalVM er hurtigere end OpenJDK,« skriver teknisk direktør Eric Sedlar, Oracle Labs i et svar til Version2.

Men det er dog muligt at give nogle fingerpeg, nævner han. Det drejer sig om applikationer, der bruger Java 8-funktioner, som streams og lambda-udtryk, programmer eller biblioteker der er skrevet i Scala (såsom Spark, som Oracle nævner specifikt,) programmer der er intensive på data, og programmer med mange abstraktioner.

GraalVM på Ubuntu i Virtualbox

Graal er ankommet i version 1.0, men kun til Linux og Mac, indtil videre. Jeg benytter ikke Linux på min maskine, så jeg bruger virtualiseringsprogrammet Virtualbox til at køre Ubuntu oven på mit Windows-system.

Jeg har først prøvet Windows Subsystem for Linux, men det kan jeg ikke få til at spille sammen med Graal. Det tager dog ikke mange minutter at komme i gang med Virtualbox.

I Ubuntu downloades og installeres GraalVM nemt med disse fire kommandoer i terminalen:

$ curl -L https://github.com/oracle/graal/releases/download/vm-1.0.0-rc9/graalvm-ce-1.0.0-rc9-linux-amd64.tar.gz -o /tmp/graal
 
$ tar -zxvf /tmp/graal -C /tmp  
 
$ sudo mv /tmp/graalvm-ce-1.0.0-rc9 /usr/lib/graalvm
 
$ export PATH=/usr/lib/graalvm/bin:$PATH

Til at teste med benytter vi kode fra Version2's machine learning-system, der gætter emneord til nye artikler. Det pågældende program har til formål at optimere en hyperparameter, og indlæser en stor mængde filer for derefter at foretage en del talknuseri.

Først oversætter vi Java-programmet til bytecode. Graal har JVM’en og dens værktøjer med i posen, så ingen ekstra krumspring er nødvendige. Vi compiler blot med den sædvanlige kommando:

$ javac v2ml/OptimeretTraener.java

Derefter compiler vi bytecode-filerne (.class) til maskinkode med kommandoen

$ native-image v2ml.OptimeretTraener

Det giver en meget lang fejlmeddelelse, der indeholder teksten

...fatal error: zlib.h: Ingen sådan fil eller filkatalog...

Den klarer vi ved at køre kommandoen

$ sudo apt-get install libz-dev

Bedre fejlmeddelelser med flag

Nu sker der noget, men programmet stopper med en fejl - uden fejlkode eller andet, der kan lede på sporet. Internettet fortæller, at hvis vi tilføjer flaget --no-server skulle vi få en bedre fejlmeddelelse:

$ native-image --no-server v2ml.OptimeretTraener

Nu får vi en fejlmeddelelse med nummeret 137, som jeg - helt usædvanligt - ikke kan finde oplysninger om på nettet ved søgning. Det skyldes nok Graals unge alder.

Seminar: Sådan tiltrækker du it-talenter til industrien

Imidlertid betyder Javas fejlkode 137 'out of memory,' og Graal er et Java-program, så mon ikke det er her, hunden ligger begravet. Vi sætter hukommelsen for Ubuntu-instansen op fra to til fire gigabyte i Virtualbox, og så går problemet væk.

Vi kører kommandoen igen og Graal kvitterer med at skabe en eksekverbar fil:

v2ml.optimerettraener

– der fylder 8,7 megabyte. Ganske pænt ned fra Java 11-distributionens 285 megabyte.

Vi kan nu teste bytecode-udgaven op imod maskinkode-versionen. Til dette formål bruger vi time-kommandoen i Ubuntus terminal, som måler, hvor lang tid det tager at udføre et program.

Bytecode-versionen kører vi således, på klassisk Java-maner:

$ time java v2ml.OptimeretTraener

Maskinkode-udgaven kører vi således:

$ time ./v2ml.optimerettraener

Det giver dette resultat, som er opsigtsvækkende - synes jeg da, i det mindste:

real    0m22,048s
user    0m18,859s
sys      0m0,568s

og

real    0m12,168s
user    0m10,500s
sys      0m0,282s

hvor real står for den faktisk forløbede tid, mens user og sys står for den CPU-tid, der kun bruges af processen.

Sponseret indhold

Ny 7-akset robot-IP løfter automation til nyt niveau: Her er specifikationerne

Automation

Vores maskinkode-udgave slår altså bytecode-versionen med en reduktion i tid på 45 procent. Ganske imponerende.

Om resultatet er påvirket af forhold, der har at gøre med at vores Ubuntu kører under Virtualbox, skal vi dog ikke kunne sige.

Windows-version på vej

Der kan være ting i verden, der er vigtigere end ydelse. Blandt Graals øvrige smarte punkter er som nævnt integration med andre sprog, som tit har underliggende biblioteker skrevet i C.

Dertil kommer, at Java kompileret til exe-filer nemt kan kaldes fra C og C++-programmer og endeligt får man et slutprodukt, som kun indeholder det nødvendige, i modsætning til hele Javas afviklingsmiljø. (Det sidste kan dog også klares med værktøjet Jlink.) Det er smart til container-brug, hvor det sparer på diskpladsen og den tid, det tager at sætte applikationen i sving.

NIS2 er en realitet: V2 Security gør dig klar til EUs massive cyber-krav

V2 Security

Ulemper er der også, naturligvis, blandt andet manglende platformsuafhængighed - der skal kompileres til enten Linux eller Mac - og dernæst kan programmer kun loade kode, som Graal har kigget på under kompilering. Men kan altså ikke loade kode via en classloader.

Andre begrænsninger i forhold til bytecode gennemgås på Graals hjemmeside. Og så er der som nævnt ikke rigtigt Windows-understøttelse endnu, men det skulle dog være på vej, forlyder det fra Oracle.