JavaVMs en GraalVM

Editor's Notes

• #2: Hallo, mijn naam is Bart Hanssens en ik werk bij de FOD BOSA DG DT Deze infosessie gaat over Java Virtual Machines - VM - en de nieuwe GraalVM.
• #3: Maar wat is Java nu precies ?
• #4: Java is niet alleen een gestandaardiseerde programmeertaal, Java is ook een complete development kit: een ontwikkelomgeving met een hele reeks libraries en tools zodat programmeurs meteen aan de slag kunnen gaan. Java code draait niet rechtstreeks op een PC maar in een "virtual machine". Dit is een erg abstracte en eenvoudige machine, die op verschillende systemen en platformen kan draaien. Hiervoor is geen JDK nodig, maar een kleinere runtime de Java Runtime Environment.
• #5: Sun Microsystems (nu Oracle) heeft Java bedacht in 1996. Een VM was toen niets nieuws, dat bestond al in de jaren 70. Waarom dan zo'n VM gebruiken ? In principe is het makkelijker om Java te implementeren op verscheidene systemen. Daarvoor moet niet de hele JDK, maar enkel de kleinere runtime overgezet kunnen worden. De code kan dan ongewijzigd draaien op allerlei systemen. Dezelfde applicatie draait dus - ongewijzigd - op Windows met Intel processor, of Linux systeem op een ARM CPU: "Write once, run everywhere"
• #6: Het is geen perfecte oplossing. De runtime is gratis, maar moet wel geinstalleerd worden. Het opstarten van deze machine neemt ook wat tijd in beslag. Misschien enkele seconden, maar dat kan al hinderlijk zijn. En na het opstarten draait de applicatie vaak wat trager dan machine-specifieke code.
• #7: In dit schema zien we het proces in werking. Een programmeur schrijft code. De compiler van de JDK zet de code om naar zogenaamde bytecode. Deze bytecode draait ongewijzigd in de runtime op Windows, Linux, Mac enzovoort. De runtime zelf, weet eigenlijk niets van Java. Ook andere talen kunnen naar bytecode omgezet worden, als er maar een compiler is. Dit is bijvoorbeeld het gevallen voor Scala, Groovy en Kotlin.
• #8: OpenJDK is een populaire JDK.
• #9: Sinds enkele jaren is dit de "reference implementation". Zoals gezegd is Java een gestandaardiseerde taal, maar omdat niet alles in detail beschreven kan worden, is deze open source versie de bijkomende maatstaf: bij twijfel over de specificatie, is de werkwijze van OpenJDK de "juiste" manier. Andere producten, zoals AdoptOpenJDK en Liberica gebruiken OpenJDK als basis, maar zijn 100% compatibel.
• #10: OpenJDK gebruikt HotSpot VM, die een compiler bevat. Deze compiler optimaliseert veelgebruikte of "hot" code. Dit gebeurt niet vooraf, maar op het moment dat de code wordt uitgevoerd, vandaar de naam "Just in Time". Dit kan op twee manieren: "client" en "server" De "client"-mode optimaliseert de opstarttijd en probeert minder geheugen te gebruiken, wat deels ten koste gaat van de snelheid van de applicatie. De "server"-mode optimaliseert voor snelheid, maar kan meer geheugen verbruiken en start ook iets trager. Vroeger moest men ofwel de ene ofwel de andere manier kiezen, tegenwoordig worden ze automatisch gecombineerd.
• #11: En nu is er dus GraalVM.
• #12: GraalVM is een project dat al heel wat jaren bestaat, maar nu is het een ondersteund product. De naam is wat misleidend, want het meer dan alleen een VM, het is eigenlijk een heel platform. Bedoeling is om een hele reeks modulaires tools te maken, die bruikbaar zijn voor meerdere programmeertalen.
• #13: GraalVM bestaat in 2 versies: een gratis "community" edition, en een betalende versie. De betalende versie is wat sneller, en heeft extra functionaliteiten. Met beide versies is het mogelijk om "polyglot" applicaties te bouwen en "native images" te genereren.
• #14: Een polyglot applicatie bevat code van andere talen Zo kan bijvoorbeeld een Java applicatie een stuk Python of Javascript uitvoeren.
• #15: Daarnaast kan GraalVM - in bepaalde gevallen - native executables maken. Dit zijn gewone applicaties die zonder aparte runtime draaien, en waar de Java bytecode wel vooraf naar machine code omgezet moet worden. Native images bevatten intern nog een sterk afgeslankte VM, SubstrateVM genaamd, om geheugenbeheer te doen. Hierdoor starten applicaties een stuk sneller, en gebruiken ze ook minder geheugen. Dit is vooral belangrijk voor "micro-services" en "serverless" applicaties, die vaak met tientallen of zelfs honderden tegelijk draaien in de cloud.
• #16: Dit is wederom niet nieuw. Voordien was er ook al een gratis compiler, GCJ, maar deze werd zelden gebruikt.Het werkt ook niet voor alle soorten Java applicaties. Bijvoorbeeld applicaties gemaakt met het "Spring" platform, kunnen vaak niet "native" worden, omdat ze heel dynamisch zijn: tijdens het draaien kunnen stukken code geladen worden, die bij het starten nog niet gekend zijn, wat het maken van native images moeilijk maakt. Hier wordt echter aan gewerkt, en bij elke versie zijn er meer mogelijkheden. Een ander nadeel is dat het compileren naar native images - eenmalig - extra tijd neemt.
• #17: Toch zit er toekomst in.
• #18: Binnen de Java community werd "project Leyden" opgestart, met als doel om "static images" te standardiseren. Static images zijn applicaties zonder de eerder vernoemde "dynamische" eigenschappen. Dit moeten dan niet per se "native images" te zijn, het is ook nuttig om applicaties te optimaliseren en verder te beveiligen. Er zijn ook steeds meer frameworks - zoals Quarkus en Micronaut - die wel gemakkelijk als native image draaien.
• #19: Voor alle duidelijkheid: de Graal compiler kan ook zonder native images gebruikt worden. Bijvoorbeeld ter vervanging van de huidige Hotspot JIT server compiler. Dit is een experimentele functie vanaf JDK versie 9, en heeft als voordeel dat de Graal compiler zelf in Java is geschreven, in plaats van in C++ (zoals de Hotspot compiler), wat het makkelijker maakt om de code te onderhouden en verder te ontwikkelen.
• #20: Tot slot nog enkele linken.
• #21: En bedankt om deze infosessie te volgen.