Здраво свима! Ово је други пост у нашој серији на Куаркусу - данас ћемо причати о изворној компилацији.
је Јава стек прилагођен за . Иако овде свакако има још много тога да се уради, урадили смо много доброг посла на многим аспектима, укључујући оптимизацију ЈВМ-а и бројних оквира. Једна од карактеристика Куаркуса која је привукла повећано интересовање програмера је његов свеобухватан, неприметан приступ претварању Јава кода у извршне датотеке за одређени оперативни систем (такозвана „природна компилација“), слично Ц и Ц++, где таква компилација обично се јавља на крају циклуса изградње, тестирања и примене.
И док је изворна компилација важна, као што ћемо показати у наставку, треба напоменути да Куаркус заиста добро ради на најобичнијој Јава машини, ОпенЈДК Хотспот, захваљујући побољшањима перформанси која смо имплементирали у целом стеку. Стога, изворну компилацију треба сматрати додатним бонусом који се може користити по жељи или потреби. У ствари, Куаркус се у великој мери ослања на ОпенЈДК када су у питању изворне слике. А дев мод, топло прихваћен од стране програмера, обезбеђује скоро тренутно тестирање промена захваљујући напредним могућностима динамичког извршавања кода имплементираних у Хотспот-у. Поред тога, када се креирају матичне ГраалВМ слике, користе се ОпенЈДК библиотека класа и ХотСпот могућности.
Па зашто вам је потребна изворна компилација ако је све већ савршено оптимизовано? Покушаћемо да одговоримо на ово питање у наставку.
Почнимо са очигледним: Ред Хат има велико искуство у оптимизацији ЈВМ-ова, стекова и оквира током развоја пројекта , укључујући:
- Први сервер апликација који ради у облаку на платформи .
- Први сервер апликација за рад на рачунарима .
- Први сервер апликација који се покреће .
- Низ пројеката који се покрећу на уређајима .
Бавили смо се изазовима покретања Јава апликација у облаку и на уређајима са ограниченим ресурсима (читај: ИоТ) дуги низ година и научили смо да извучемо максимум из ЈВМ-а у смислу перформанси и оптимизације меморије. Као и многи други, већ дуже време радимо са изворном компилацијом Јава апликација , , па чак и и добро смо свесни предности и недостатака овог приступа (на пример, дилема избора између универзалности „направи једном – покрени било где“ и чињенице да су компајлиране апликације мање и да раде брже).
Зашто је важно размотрити ове предности и недостатке? Зато што у неким ситуацијама њихов однос постаје одлучујући:
- На пример, у окружењима без сервера/догађајима где у (тврдом или меком) реалном времену како би имао времена да одговори на догађаје. За разлику од дуготрајних упорних услуга, овде трајање хладног старта критично повећава време одговора на захтев. ЈВМ-у је и даље потребно значајно време да се покрене, и док се то у неким случајевима може смањити чистим хардверским методама, разлика између једне секунде и 5 милисекунди може бити разлика између живота и смрти. Да, овде се можете поиграти са стварањем вруће резерве Јава машина (што смо, на пример, урадили са ), али ово само по себи не гарантује да ће постојати довољно ЈВМ-ова за обраду захтева како се оптерећење повећава. А са економске тачке гледишта, ово вероватно није најисправнија опција.
- Даље, постоји још један аспект који се често појављује: вишестанарство. Упркос чињеници да су се ЈВМ-ови по својим могућностима веома приближили оперативним системима, они још увек нису способни да ураде оно на шта смо навикли у Линук-у – изоловање процеса. Према томе, квар једне нити може срушити целу Јава машину. Многи људи покушавају да заобиђу овај недостатак тако што ће за сваку корисничку апликацију посветити посебан ЈВМ како би минимизирали последице неуспеха. Ово је сасвим логично, али се не уклапа добро са скалирањем.
- Поред тога, за апликације оријентисане на облак, важан индикатор је густина услуга на хосту. Прелазак на методологију , микросервис и Кубернетес повећава број Јава машина по апликацији. Односно, с једне стране, све ово обезбеђује еластичност и поузданост, али се истовремено повећава и потрошња базне меморије у смислу услуге, а неки од ових трошкова нису увек стриктно неопходни. Статички компајлирани извршни фајлови овде имају користи због различитих техника оптимизације, као што је елиминација мртвог кода ниског нивоа, када коначна слика укључује само оне делове оквира (укључујући сам ЈДК) које услуга заправо користи. Стога, Куаркус изворна компилација помаже да се инстанце услуге густо смести на хост без угрожавања безбедности.
Заправо, горе наведени аргументи су већ довољни да се разуме оправданост нативне компилације са становишта учесника Куаркус пројекта. Међутим, постоји још један, нетехнички, али такође важан разлог: последњих година многи програмери и развојне компаније напуштају Јаву у корист нових програмских језика, верујући да је Јава, заједно са својим ЈВМ-овима, стековима и оквирима, постала превише гладан памћења, сувише спор, итд.
Међутим, навика да се користи исти алат за решавање било ког проблема је . Понекад је боље направити корак уназад и потражити нешто друго. А ако Куаркус тера људе да застану и размишљају, онда је то добро за цео Јава екосистем. Куаркус представља иновативан поглед на то како да се изгради ефикасније апликације, чинећи Јаву релевантнијом за нове архитектуре апликација као што је без сервера. Поред тога, због своје проширивости, Куаркус ће, надамо се, имати читав екосистем Јава екстензија, значајно повећавајући број оквира који ће подржавати изворну компилацију у апликацијама из кутије.
Извор: ввв.хабр.цом