PĂ«rshĂ«ndetje tĂ« gjithĂ«ve! Kemi postimin e dytĂ« nga seria jonĂ« pĂ«r Quarkus â sot do tĂ« flasim mbi kompilimin natyral.
â Ă«shtĂ« njĂ« stak Java, i optimizuar pĂ«r . Edhe pse, natyrisht, ka shumĂ« pĂ«r tĂ« bĂ«rĂ« kĂ«tu, ne kemi punuar mirĂ« mbi shumĂ« aspekte, pĂ«rfshirĂ« optimizimin e JVM dhe njĂ« varg framework-esh. NjĂ« nga veçoritĂ« e Quarkus qĂ« ka tĂ«rhequr interes tĂ« madh nga zhvilluesit Ă«shtĂ« qasja komplekse dhe pa brez nĂ« transformimin e kodit Java nĂ« skedarĂ« ekzekutues pĂ«r sistemin operativ specifik (e njohur si "kompilimi natyral"), nĂ« mĂ«nyrĂ« tĂ« ngjashme me C dhe C++, ku njĂ« kompilim i tillĂ« zakonisht ndodh nĂ« fund tĂ« ciklit tĂ« ndĂ«rtimit, testimit dhe implementimit.
Edhe pse kompilimi natyral, siç do ta tregojmë më poshtë, është i rëndësishëm, duhet të thuhet se Quarkus punon shumë mirë edhe në makinën standarde Java OpenJDK Hotspot për shkak të përmirësimeve të performancës që kemi zbatuar në të gjithë stakun. Prandaj, kompilimi natyral duhet të shihet si një përfitim shtesë që mund të përdoret sipas dëshirës ose nevojës. Në të vërtetë, kur bëhet fjalë për imazhet natyrale, Quarkus në masë të madhe mbështetet te OpenJDK. Ndërkohë, moda dev e pritur mirë nga zhvilluesit ofron testim pothuajse të menjëhershëm të ndryshimeve përmes mjeteve të zhvilluara për ekzekutimin dinamik të kodit, të realizuara në Hotspot. Për më tepër, gjatë krijimit të imazheve natyrale, GraalVM aktivizon bibliotekën e klasave OpenJDK dhe mundësitë e HotSpot.
Pra, përse na nevojitet kompilimi natyral, nëse gjithçka është optimizuar kaq mirë? Në këtë pyetje do të përpiqemi të përgjigjemi më poshtë.
Le të fillojmë me të dukshmen: Red Hat ka shumë përvojë në optimizimin e JVM, stack-ëve dhe framework-eve gjatë zhvillimit të projektit , duke përfshirë:
- Serveri i parë i aplikacioneve për të punuar në cloud mbi platformën .
- Serveri i parë i aplikacioneve për të punuar në komputerat .
- Serveri i parë i aplikacioneve për të punuar në .
- Një gamë të gjerë projektesh që funksionojnë në pajisje .
Ne jemi angazhuar prej vitesh nĂ« zgjidhjen e problemeve tĂ« ekzekutimit tĂ« aplikacioneve Java nĂ« cloud dhe nĂ« pajisje me burime tĂ« kufizuara (lexo, IoT) dhe kemi mĂ«suar tĂ« nxjerrim maksimumin nga JVM nĂ« aspektin e performancĂ«s dhe optimizimit tĂ« memories. Ashtu si shumĂ« tĂ« tjerĂ«, ne kemi punuar prej kohĂ«sh me kompilimin natyral tĂ« aplikacioneve Java pĂ«rmes , , dhe madje dhe e kuptojmĂ« mirĂ« pĂ«rfitimet dhe disavantazhet e kĂ«tij qasje (pĂ«r shembull, dilemĂ«n e zgjedhjes midis universialitetit "build once â run-anywhere" dhe faktit se aplikacionet e kompilura kanĂ« njĂ« pĂ«rmasĂ« mĂ« tĂ« vogĂ«l dhe fillojnĂ« mĂ« shpejt).
Pse është kaq e rëndësishme të merret parasysh këto përfitime dhe disavantazhe? Sepse në disa situata proporcioni i tyre bëhet vendimtar:
- Për shembull, në ambientet serverless/ndërvepruese me ngjarje, ku në modin (të ashpër ose të butë) të kohës reale, për t'u përgjigjur në kohë ndaj ngjarjeve. Ndryshe nga shërbimet e qëndrueshme me jetë të gjatë, këtu, koha e ftohjes kritikon rëndë kohën e përgjigjes ndaj kërkesave. Akoma merr një kohë të konsiderueshme për fillimin e JVM, dhe megjithëse në disa raste mund të shkurtohet përmes metodave të pastra harduerike, ndryshimi midis një sekonde dhe 5 milisekondave mund të jetë një çështje jete dhe vdekje. Po, këtu mund të eksperimentojmë me krijimin e një rezervë të nxehtë të makinave Java (siç e kemi bërë, për shembull, gjatë ), por vetë kjo nuk garanton numrin e mjaftueshëm të JVM për të trajtuar kërkesat në përputhje me ngarkesën. Edhe nga pikëpamja ekonomike, kjo, sigurisht, nuk është zgjidhja më e mirë.
- MĂ« tej, ka njĂ« aspekt tjetĂ«r qĂ« shpesh paraqitet, siç Ă«shtĂ« multitensionimi. MegjithĂ«se JVM ka arritur shumĂ« afĂ«r mundĂ«sive tĂ« sistemeve operative, ato ende nuk janĂ« nĂ« gjendje tĂ« bĂ«jnĂ« atĂ« qĂ« jemi mĂ«suar me tĂ« nĂ« Linux â tĂ« izolojnĂ« proceset. KĂ«shtu qĂ« njĂ« dĂ«shtim i njĂ« thase mund tĂ« dĂ«shtojĂ« tĂ« gjithĂ« makinĂ«n Java. ShumĂ« pĂ«rpiqen ta anashkalojnĂ« kĂ«tĂ« disavantazh duke ndarĂ« njĂ« JVM tĂ« veçantĂ« pĂ«r aplikacionet e çdo pĂ«rdoruesi, pĂ«r tĂ« minimizuar pasojat e dĂ«shtimit. Kjo Ă«shtĂ« krejt logjike, por nuk pĂ«rshtatet mirĂ« me shkallĂ«zimin.
- Përveç kësaj, për aplikacionet e orientuara në cloud, një tregues i tillë si densiteti i shërbimeve në host është i rëndësishëm. Kalimi në metodologjinë , mikroservisët dhe Kubernetes rrisin numrin e makinave Java për një aplikacion. Kështu, nga njëra anë, gjithçka kjo ofron elasticitet dhe besueshmëri, por njëkohësisht rritet edhe shpenzimi i memorjes bazë për çdo shërbim, për më tepër, një pjesë e këtyre shpenzimeve shpesh nuk është absolutisht e nevojshme. Skedarët ekzekutivë të kompiluar statikisht përfitojnë këtu nga teknika të ndryshme optimizimi, si eliminimi i kodit të vdekur në nivel të ulët, kur në imazhin përfundimtar përfshihen vetëm ato pjesë të kuadrit (përfshirë dhe JDK-në e vet) që shërbimi realizohet vërtet. Prandaj, kompilimi natyror i Quarkus ndihmon në vendosjen më të ngjeshur të kopjeve të shërbimeve në host pa kompromise për sigurinë.
Argumentet e sipërpërmendura janë tashmë të mjaftueshme për të kuptuar arsyeshmërinë e kompiluese natyrore nga pikëpamja e pjesëmarrësve në projektin Quarkus. Megjithatë, ekziston edhe një arsye tjetër, jo teknike, por njësoj e rëndësishme: vitet e fundit shumë programues dhe kompani zhvilluesh janë distancuar nga Java në favor të gjuhëve të reja të programimit, duke e konsideruar Java-n së bashku me JVM-të e saj, stakët dhe kuadrot si shumë të pangopura në lidhje me memorjen, tepër të ngadalta, etj.
MegjithatĂ«, zakoni pĂ«r tĂ« pĂ«rdorur tĂ« njĂ«jtin mjet pĂ«r zgjidhjen e çdo problemi â . NdonjĂ«herĂ« Ă«shtĂ« mĂ« mirĂ« tĂ« bĂ«sh njĂ« hap prapa dhe tĂ« kĂ«rkosh diçka tjetĂ«r. Dhe nĂ«se Quarkus i bĂ«n njerĂ«zit tĂ« ndalojnĂ« dhe tĂ« mendojnĂ«, atĂ«herĂ« kjo Ă«shtĂ« e mirĂ« pĂ«r tĂ«rĂ« ekosistemin Java. Quarkus pĂ«rfaqĂ«son njĂ« qasje novatore pĂ«r krijimin e aplikacioneve mĂ« efikase, duke e bĂ«rĂ« Java-n mĂ« tĂ« rĂ«ndĂ«sishme pĂ«r arkitekturat e reja tĂ« aplikacioneve, si p.sh. serverless. PĂ«r mĂ« tepĂ«r, falĂ« zgjerueshmĂ«risĂ« sĂ« tij, shpresojmĂ« se Quarkus do tĂ« ketĂ« njĂ« ekosistem tĂ« tĂ«rĂ« Java-zhvillimesh, duke rritur ndjeshĂ«m numrin e kuadrove qĂ« do tĂ« mbĂ«shtesin natyrisht kompilimin natyror si pjesĂ« e aplikacioneve.
Burimi: habr.com
