Natiivkompileerimine Quarkuses – miks see on oluline

Tere kõigile! Täna on meil teine postitus meie Quarkus'i seerias – räägime täna natiivkompileerimisest.

Quarkus on Java-tehnoloogiate kogum, mis on optimeeritud Kubernetes. Kuigi siin on veel palju teha, oleme põhjalikult töötanud mitmete aspektide kallal, sealhulgas JVM-i ja erinevate raamistikute optimeerimise. Üks Quarkus'e silmapaistvamaid jooni, mis on arendajate seas palju huvi tekitanud, on põhjalik ja sujuv lähenemine Java-koodi kompileerimisele täidetavateks failideks konkreetse operatsioonisüsteemi jaoks (nn 'natiivkompileerimine'), sarnaselt C ja C++-le, kus selline kompileerimine toimub tavaliselt kogu tsükli lõpus, mis koosneb kokku kogumisest, testimisest ja juurutamisest.

Ja kuigi natiivkompileerimine, nagu me allpool näitame, on oluline, tuleb märkida, et Quarkus töötab väga hästi ka tavalisel OpenJDK Hotspoti Java-masinal, tänu meie rakendatud jõudluse parendustele kogu tehnoloogia alla. Seetõttu tuleks natiivkompileerimist käsitleda kui lisaboonust, mida saab kasutada soovi või vajaduse korral. Tegelikult toetub Quarkus natiivsete piltide osas suurel määral OpenJDK-le. Ja arendajate poolt hästi vastu võetud arendusseisund, dev mode, võimaldab praktiliselt kohest muutuste testimist arenduskeskkonnas, tänu arenenud dünaamilise koodi täitmise võimalustele, mis on rakendatud Hotspotis. Lisaks kasutatakse natiivsete piltide loomisel GraalVM-i puhul OpenJDK klasside teeki ja HotSpot'i võimeid.

Miks on siis natiivkompileerimine vajalik, kui kõik on juba nii hästi optimeeritud? Sellele küsimusele püüame allpool vastata.

Alustame ilmsest: Red Hat'il on suur kogemus JVM-i, tehnoloogiakogumite ja raamistikute optimeerimisega projekti ajal. JBoss, sealhulgas:

• Esimene pilve jaoks loodud rakenduste server, mis töötab Red Hat OpenShift.
• Esimene rakenduste server, mis töötab arvutites Plug PC.
• Esimene rakenduste server, mis töötab Raspberry Pi.
• Mitmed projektid, mis töötavad seadmetes Android.

Oleme juba aastaid tegelenud Java-rakenduste käivitamise probleemidega pilves ja piiratud ressurssidega seadmetes (loe: IoT) ning oleme õppinud JVM-ist maksimumi saavutama jõudluse ja mälutasude optimeerimise osas. Nagu paljud teised, oleme juba ammu töötanud Java rakenduste natiivkompileerimisega läbi GCJ, Avian, Excelsior JET ja isegi Dalvik ja ja oleme täiesti teadlikud sellise lähenemise plussidest ja miinustest (näiteks dilemma universaalsuse "valmista üks kord – käivita kõikjal" ning selle vahel, et kompileeritud rakendused on väiksema suurusega ja käivitatakse kiiremini).

Miks on oluline arvestada neid plusse ja miinusi? Sest mõnedes olukordades muutub nende suhe otsustavaks:

• Näiteks serverless/haldamise ürituste keskkondades, kus teenused peavad tingimata käivituma reaalajas (karmis või leebes režiimis), et olla suuteline reageerima sündmustele. Erinevalt pikaajalistest püsivatest teenustest, siin pikendab külmkäivitamise aeg kriitiliselt vastamisaega päringule. JVM-i käivitamiseks kulub endiselt märkimisväärselt aega ja kuigi teatud olukordades saab seda puhtalt riistvaraliste meetoditega lühendada, võib erinevus ühe sekundi ja 5 millisekundi vahel olla elu ja surma küsimus. Jah, siin saab mängida Java-masinate kuumreserveerimise loomisega (mida me näiteks tegime), portides OpenWhiski Knative'ile), kuid ainult see ei garanteeri piisavat JVM-id, et töötlemiseks nõutavat arvu nõudmiste suurenedes. Ja ökonoomsuse seisukohalt ei ole see kindlasti kõige õigem valik.
• Edasi, on veel üks sageli esinev aspekt, nagu multitenantsus. Kuigi JVM on oma võimalustes jõudnud operatsioonisüsteemidele lähedale, ei suuda nad endiselt teha seda, millega oleme Linuxis harjunud – isoleerida protsesse. Seetõttu võib ühe voolu rike rikkuda kogu Java-masina. Paljud püüavad selle puuduse ületamiseks eraldada igale kasutajale eraldi JVM, et minimeerida rikke tagajärgi. See on üsna loogiline, kuid halvasti sobitub skaleerimisega.
• Lisaks on pilvealuste rakenduste jaoks oluline selline näitaja nagu teenuste tihedus hostil. Üleminek 12 rakenduse teguritest, mikrosysteemid ja Kubernetes suurendavad Java-masinate arvu ühe rakenduse kohta. Seega, ühelt poolt, pakub see paindlikkust ja usaldusväärsust, kuid samal ajal suureneb ka põh mälu kulu teenuse kohta, kusjuures osa nendest kuludest ei ole alati rangelt vajalikud. Staatiliselt kompileeritud täitmisfailid saavavad siin kasu erinevatest optimeerimisetehnikatest, nagu madala taseme dead-code elimination, kus lõplikku pilti lisatakse ainult need raamistikud (sealhulgas ka JDK), mida teenus tegelikult kasutab. Seetõttu aitab Quarkuse natiivne kompileerimine teenuse instantside tihedamat paigutust hostis ilma turvalisusele kahju tekitamata.

Ükski ülaltoodud argumentidest on piisav, et mõista natiivse kompileerimise õigustatust Quarkuse projektis osalejate vaatepunktist. Siiski on veel üks, mitte tehniline, kuid samuti oluline põhjus: viimastel aastatel on paljud arendajad ja arendusettevõtted loobunud Java kasutamisest uute programmeerimiskeelte kasuks, arvates, et Java koos oma JVM-i, stekkide ja raamistikudega on muutunud liiga mäluhimu järgi, ülemäära aeglaseks jne.

Kuid harjumus kasutada sama tööriista erinevate probleemide lahendamiseks – see ei ole alati õige. Mõnikord on parem astuda samm tagasi ja otsida midagi muud. Ja kui Quarkus sunnib inimesi peatuma ja järele mõtlema, siis on see hea kogu Java ökosüsteemi jaoks. Quarkus kehastab uuenduslikku lähenemist sellele, kuidas luua efektiivsemaid rakendusi, muutes Java uutele rakenduste arhitektuuridele, nagu serverita, asjakohasemaks. Lisaks, tänu oma laiendatavusele, loodame, et Quarkusele tekib terve Java laienduste ökosüsteem, mis suurendab märkimisväärselt raamistike arvu, mis toovad natiivse kompileerimise rakenduste koostisosana automaatselt.

Allikas: habr.com