Мајчин компилација во Quarkus - зошто е важна

Здраво на сите! Ова е втор пост во нашата серија на Quarkus - денес ќе зборуваме за мајчин компилација.

Кваркус е Java стек прилагоден за Кубернети. Иако тука сигурно има многу повеќе да се направи, ние направивме многу добра работа на многу аспекти, вклучително и оптимизирање на JVM и голем број рамки. Една од карактеристиките на Quarkus што привлече зголемен интерес кај програмерите е неговиот сеопфатен, беспрекорен пристап за претворање на Java кодот во извршни датотеки за специфичен оперативен систем (т.н. „народна компилација“), слично на C и C++, каде што таквата компилација обично се случува на крајот од циклусот на изградба, тестирање и распоредување.

И додека домашната компилација е важна, како што ќе покажеме подолу, треба да се забележи дека Quarkus работи навистина добро на најчестата Java машина, OpenJDK Hotspot, благодарение на подобрувањата на перформансите што ги имплементиравме низ целиот стек. Затоа, мајчината компилација треба да се смета како дополнителен бонус што може да се користи по желба или потреба. Всушност, Quarkus во голема мера се потпира на OpenJDK кога станува збор за мајчин слики. И режимот на dev, топло прифатен од програмерите, обезбедува речиси моментално тестирање на промените поради напредните можности за динамично извршување на кодот имплементиран во Hotspot. Дополнително, при креирање на природни слики на GraalVM, се користат библиотеката на класата OpenJDK и способностите HotSpot.

Па, зошто ви е потребна домашна компилација ако сè е веќе совршено оптимизирано? Ќе се обидеме да одговориме на ова прашање подолу.

Да почнеме со очигледното: Red Hat има големо искуство во оптимизирање на JVM, стекови и рамки за време на развојот на проектот JBoss, вклучувајќи:

• Првиот сервер за апликации што работи во облакот на платформата Red Hat OpenShift.
• Првиот сервер за апликации за работа на компјутери Приклучете го компјутерот.
• Првиот сервер за апликации на кој работи Малина Пи.
• Низа проекти што работат на уреди Андроид.

Долги години се справуваме со предизвиците на водење Java апликации во облакот и на уреди со ограничени ресурси (читај: IoT) и научивме да го извлечеме максимумот од JVM во однос на перформансите и оптимизацијата на меморијата. Како и многу други, долго време работиме со природна компилација на Java апликации ГЦЈ, Птичји, Excelsior JET па дури и Dalvik и добро сме свесни за добрите и лошите страни на овој пристап (на пример, дилемата за избор помеѓу универзалноста на „изгради еднаш – бегај-секаде“ и фактот дека компајлираните апликации се помали и работат побрзо).

Зошто е важно да се земат предвид овие добрите и лошите страни? Бидејќи во некои ситуации нивниот сооднос станува одлучувачки:

• На пример, во средини без сервери/управувани од настани каде услугите едноставно мора да започнат во (тврдо или меко) реално време за да имате време да одговорите на настаните. За разлика од долготрајните постојани услуги, овде времетраењето на студениот почеток критично го зголемува времето на одговор на барање. На JVM сè уште му треба значително време за да се стартува, и иако тоа може да се намали во некои случаи со чисти хардверски методи, разликата помеѓу една секунда и 5 милисекунди може да биде разликата помеѓу животот и смртта. Да, овде можете да си играте со создавање на топла резерва на Java машини (што, на пример, го направивме со пренесување OpenWhisk на Knative), но ова само по себе не гарантира дека ќе има доволно JVM за обработка на барањата како што се скалила оптоварувањето. И од економска гледна точка, ова веројатно не е најправилната опција.
• Понатаму, постои уште еден аспект што често се појавува: мултизакуп. И покрај фактот дека JVM се доближија многу блиску до оперативните системи во нивните можности, тие сè уште не се способни да го прават она на што сме толку навикнати во Linux - процесите на изолација. Затоа, неуспехот на една нишка може да ја урне целата Java машина. Многу луѓе се обидуваат да го заобиколат овој недостаток со посветување на посебен JVM за апликација на секој корисник со цел да ги минимизираат последиците од дефект. Ова е сосема логично, но не се вклопува добро со скалирање.
• Покрај тоа, за апликациите ориентирани кон облак, важен индикатор е густината на услугите на домаќинот. Транзиција кон методологија 12 фактори на примена, microservices и Kubernetes го зголемува бројот на Java машини по апликација. Односно, од една страна, сето ова обезбедува еластичност и сигурност, но во исто време се зголемува и потрошувачката на базната меморија во однос на услугата, а некои од овие трошоци не се секогаш строго неопходни. Статички компајлираните извршни датотеки тука имаат корист поради различните техники за оптимизација, како што е елиминацијата на мртвиот код на ниско ниво, кога конечната слика ги вклучува само оние делови од рамките (вклучувајќи го и самиот JDK) што услугата всушност ги користи. Затоа, природната компилација на Quarkus помага густо да се постават примероци на услуги на домаќинот без да се загрози безбедноста.

Всушност, горенаведените аргументи се веќе доволни за да се разбере оправданоста на природната компилација од гледна точка на учесниците во проектот Quarkus. Сепак, постои уште една, нетехничка, но и важна причина: во последниве години, многу програмери и развојни компании ја напуштија Java во корист на нови програмски јазици, верувајќи дека Java, заедно со нејзините JVM, стекови и рамки, стана премногу гладен за меморија, премногу бавен, итн.

Сепак, навиката да се користи истата алатка за решавање на каков било проблем е не е секогаш во право. Понекогаш е подобро да направите чекор назад и да барате нешто друго. И ако Quarkus ги натера луѓето да паузираат и размислуваат, тогаш тоа е добро за целиот екосистем на Јава. Quarkus претставува иновативен поглед за тоа како да се изградат поефикасни апликации, правејќи ја Java порелевантна за новите архитектури на апликации како што е без сервер. Покрај тоа, поради неговата екстензивност, Quarkus се надеваме дека ќе има цел екосистем на Java екстензии, значително зголемувајќи го бројот на рамки кои ќе поддржуваат мајчин компилација во апликации надвор од кутијата.

Извор: www.habr.com