Bok svima! Ovo je drugi post u našoj seriji o Quarkusu - danas ćemo govoriti o izvornoj kompilaciji.
je Java stack prilagođen za . Iako ovdje sigurno ima puno više za napraviti, napravili smo puno dobrog posla na mnogim aspektima, uključujući optimizaciju JVM-a i niza okvira. Jedna od značajki Quarkusa koja je privukla povećani interes programera je njegov sveobuhvatan, besprijekoran pristup pretvaranju Java koda u izvršne datoteke za određeni operacijski sustav (tzv. "nativna kompilacija"), slično C i C++, gdje takva kompilacija obično se događa na kraju ciklusa izgradnje, testiranja i postavljanja.
I dok je izvorna kompilacija važna, kao što ćemo pokazati u nastavku, treba primijetiti da Quarkus stvarno dobro radi na najčešćem Java stroju, OpenJDK Hotspotu, zahvaljujući poboljšanjima performansi koja smo implementirali kroz cijeli stog. Stoga nativnu kompilaciju treba smatrati dodatnim bonusom koji se može koristiti po želji ili potrebi. Zapravo, Quarkus se uvelike oslanja na OpenJDK kada su u pitanju izvorne slike. A način rada za razvojne programere, toplo prihvaćen od strane programera, osigurava gotovo trenutačno testiranje promjena zahvaljujući naprednim mogućnostima dinamičkog izvršavanja koda implementiranih u Hotspotu. Osim toga, pri stvaranju izvornih GraalVM slika koristi se OpenJDK biblioteka klasa i HotSpot mogućnosti.
Dakle, zašto vam je potrebna izvorna kompilacija ako je sve već savršeno optimizirano? U nastavku ćemo pokušati odgovoriti na ovo pitanje.
Počnimo s očitim: Red Hat ima veliko iskustvo u optimizaciji JVM-ova, nizova i okvira tijekom razvoja projekta , uključujući:
- Prvi aplikacijski poslužitelj koji radi u oblaku na platformi .
- Prvi aplikacijski poslužitelj za rad na računalima .
- Prvi aplikacijski poslužitelj na kojem će se izvoditi .
- Niz projekata koji se izvode na uređajima .
Dugi niz godina nosimo se s izazovima pokretanja Java aplikacija u oblaku i na uređajima s ograničenim resursima (čitaj: IoT) i naučili smo izvući maksimum iz JVM-a u smislu performansi i optimizacije memorije. Kao i mnogi drugi, već duže vrijeme radimo s izvornom kompilacijom Java aplikacija , , , pa čak i i dobro smo svjesni prednosti i mana ovog pristupa (na primjer, dilema izbora između univerzalnosti "sagradi jednom – pokreni bilo gdje" i činjenice da su kompajlirane aplikacije manje i rade brže).
Zašto je važno razmotriti ove prednosti i nedostatke? Jer u nekim situacijama njihov omjer postaje odlučujući:
- Na primjer, u okruženjima bez poslužitelja/pokrenutim događajima gdje u (tvrdom ili mekom) stvarnom vremenu kako bi imali vremena odgovoriti na događaje. Za razliku od dugotrajnih postojanih usluga, ovdje trajanje hladnog pokretanja kritično povećava vrijeme odgovora na zahtjev. JVM još uvijek treba dosta vremena da se pokrene, i dok se to u nekim slučajevima može smanjiti čistim hardverskim metodama, razlika između jedne sekunde i 5 milisekundi može biti razlika između života i smrti. Da, ovdje se možete poigrati sa stvaranjem vruće rezerve Java strojeva (što smo, na primjer, učinili s ), ali to samo po sebi ne jamči da će biti dovoljno JVM-ova za obradu zahtjeva kako se opterećenje bude skaliralo. A s ekonomske točke gledišta, ovo vjerojatno nije najispravnija opcija.
- Nadalje, postoji još jedan aspekt koji se često pojavljuje: višestanarstvo. Unatoč činjenici da su se JVM po svojim mogućnostima jako približili operativnim sustavima, još uvijek nisu sposobni raditi ono na što smo navikli u Linuxu - izolirati procese. Stoga, kvar jedne niti može srušiti cijeli Java stroj. Mnogi ljudi pokušavaju zaobići ovaj nedostatak dodjeljivanjem zasebnog JVM-a za svaku korisničku aplikaciju kako bi se smanjile posljedice kvara. To je sasvim logično, ali ne pristaje dobro uz skaliranje.
- Osim toga, za aplikacije orijentirane na oblak važan pokazatelj je gustoća usluga na hostu. Prijelaz na metodologiju , mikroservisi i Kubernetes povećavaju broj Java strojeva po aplikaciji. Odnosno, s jedne strane sve to daje elastičnost i pouzdanost, ali istovremeno se povećava i potrošnja osnovne memorije u servisnom smislu, a neki od tih troškova nisu uvijek striktno potrebni. Statički kompajlirane izvršne datoteke ovdje imaju koristi zbog različitih tehnika optimizacije, kao što je eliminacija mrtvog koda niske razine, kada konačna slika uključuje samo one dijelove okvira (uključujući sam JDK) koje usluga stvarno koristi. Stoga Quarkus izvorna kompilacija pomaže gusto postaviti instance usluge na host bez ugrožavanja sigurnosti.
Zapravo, gornji argumenti već su dovoljni za razumijevanje opravdanosti izvorne kompilacije sa stajališta sudionika projekta Quarkus. Međutim, postoji još jedan, netehnički, ali također važan razlog: posljednjih su godina mnogi programeri i razvojne tvrtke napustile Javu u korist novih programskih jezika, vjerujući da je Java, zajedno sa svojim JVM-ovima, nizovima i okvirima, postala previše gladan pamćenja, presporo itd.
Međutim, navika korištenja istog alata za rješavanje bilo kojeg problema jest . Ponekad je bolje napraviti korak unatrag i potražiti nešto drugo. A ako Quarkus natjera ljude da zastanu i razmisle, onda je to dobro za cijeli Java ekosustav. Quarkus predstavlja inovativan pogled na to kako izgraditi učinkovitije aplikacije, čineći Javu relevantnijom za nove arhitekture aplikacija kao što je serverless. Osim toga, zbog svoje proširivosti, Quarkus će, nadamo se, imati cijeli ekosustav Java ekstenzija, značajno povećavajući broj okvira koji će podržavati izvornu kompilaciju u aplikacijama odmah po otvaranju.
Izvor: www.habr.com