Java 9 får Ahead-of-Time-compiler for hurtigere opstart

Java har hidtil bygget på en kraftig Just-in-Time compiler, men det giver ikke altid det bedste resultat. Nu bliver en Ahead-of-Time compiler en indbygget mulighed i Java 9.

Der bliver rykket ved én af grundpillerne i Java-platformen, når Java 9 bliver klar. Det er nemlig besluttet at gøre Ahead-of-Time compileren Graal til en indbygget del af Java 9, fremgår det af en post på OpenJDK-projektet.

Det betyder, at det vil være muligt for udviklere at vælge at compilere deres kode, før den køres. Det skal afhjælpe de situationer, hvor applikationen skal startes hurtigt, og hvor man derfor kan komme til at vente på, at Javas normale Just-in-Time compiler er klar med bytecode.

Det er ikke meningen, at Java skal være et præcompileret sprog med libraries som det kendes fra eksempelvis C++, men udviklere skal altså have muligheden for at vælge at compilere dele af deres applikation på forhånd.

Just-in-Time compileren vil stadig have en fordel, når det gælder optimering af koden, fordi den vil kunne optimere mere præcist på profilen for applikationens afvikling.

OpenJDK er der, hvor nye funktioner i Java afprøves, og det er herfra de plukkes til den officielle Java-udgave. Derefter udgives først udviklerversionen JDK, dernæst en Standard-version SE og til sidst Enterprise-versionen EE, som er den til store driftsmiljøer.

Ahead-of-Time compiler-muligheden er da også mest rettet mod applikationer på servere, for i første omgang vil den kun være tilgængelig på 64 bit Linux-installationer, som er det mest almindelige servermiljø for Java. Det er altså ikke meningen, at man skal distribuere klientprogrammer som compilet kode.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Anders Kreinøe

Er jeg den eneste der synes at det lyder lidt underlidt, at funktionen skulle være serverrettet, hvis formålet er at give hurtigere opstart tider på programmet.

Umiddelbart tænker jeg a hurtigere opstart tid ville være væsentligt mere eftertragtet på en klient side. På server siden er man ofte ret ligeglad med om ens application starter op på 15 eller 20 sekunder.

Er der noget jeg har misforstået?

  • 2
  • 0
#3 Sune Marcher

Umiddelbart tænker jeg a hurtigere opstart tid ville være væsentligt mere eftertragtet på en klient side. På server siden er man ofte ret ligeglad med om ens application starter op på 15 eller 20 sekunder.

Det kunne måske være interessant i forbindelse med dynamisk load-håndtering hvor du først spinner op når behovet er der - et scenarie der ikke har været super gunstigt for Java so far (omend f.eks. AWS Lambda supporter det).

  • 2
  • 0
#4 Casper Bang

Er jeg den eneste der synes at det lyder lidt underlidt, at funktionen skulle være serverrettet, hvis formålet er at give hurtigere opstart tider på programmet.

Nej, men de leger jo "catch up" med Google og Android, der i dén grad har formået at eksekvere på en "embrace and extend" strategi der ikke er set gjort bedre siden Microsofts storhedstid. Google har jo med overgangen fra Dalvik til ART netop bevist at AoT kan give store fordele, men som du selv er inde på, er klient Java jo stort set død - så det har næppe den store praktiske betydning. Jeg tror personligt mere det handler om strategi, i et retsopgør imellem Google og Oracle vil sidstnævnte ikke stå tilbage med et ringere klient produkt.

  • 1
  • 0
#5 Morten Olsen

JIT oversættelse spiller dårligt sammen med Copy-On-Write. Med AOT vil applikationer kunne dele mere. Med den "nye" fokus på containere istedet for virtualisering, så burde det give en stor fordel

  • 0
  • 0
#6 Jacob Nordfalk

Nej, men de leger jo "catch up" med Google og Android, der i dén grad har formået at eksekvere på en "embrace and extend" strategi der ikke er set gjort bedre siden Microsofts storhedstid.

Du tænker nok på https://da.wikipedia.org/wiki/Embrace_extend_and_extinguish .

Men strategiens punkt 2 er ikke opfyldt (og dermed heller ikke punkt 3) :

2) Extend: Man tilfører funktioner, som ikke understøttes af det konkurrerende produkt eller ikke er en del af standarden, sådan at man skaber problemer for kunder, der forsøger at bruge den oprindelige, 'simple' standard.

Google/Android har ikke lavet om i Javas API eller SDK. Alt der kun bruger Java fungerer fint på desktoppen. Standarden er uændret.

Google tilfører nye funktioner til Android, ja, men de er meget klart adskilt fra Javas API og SDK - ingen udviklere på Android bliver på nogen måde 'lullet ind' i at tro at det, de laver også fungerer i desktop Java.

I øvrigt er ART open source under Apache licensen - se https://android.googlesource.com/platform/art - ligesom resten af Android.

Det undrer mig en del at Java-miljøet aldrig har diskuteret om Googles arbejde her ville være værd at bygge på. Deres DEX bytekodeformat har også en række fordele - det er meget mere kompakt og hurtigere at indlæse end Java bytekode fordi det er prælinket (en JAR-fil er en ZIP-fil med en masse uafhængige .class-filer med hvert sit sæt symboler der skal linkes sammen ved indlæsning - en DEX-fil kan sidestilles med en jumbo-class-fil med kun ét sæt symboler) Derudover kommer arbejdet med Jack og Jill

  • 1
  • 0
Log ind eller Opret konto for at kommentere