HotSpot: нове покоління віртуальних машин

1. Sun розробила динамічний компілятор нового покоління, що генерує принципово інший байт-код
2. ВИХІДНА ТОЧКА: розігрівати ДВИГУНИ
3. ПОЇХАЛИ! "І плавиться асфальт, протектор кип'ятити"
4. "Прибирання сміття" і синхронізація
5. Як працює динамічний компілятор
6. Профілювальники і евристична компіляція
7. Переваги динамічної компіляції
8. Критерії ефективності динамічної компіляції
9. HotSpot в порівнянні з "рідним" кодом
10. ФІНІШ? НУ ЩО ВИ, ГОНКА ТІЛЬКИ ПОЧИНАЄТЬСЯ!
11. ЯК ПРАЦЮЮТЬ Компілятори та інтерпретатори
12. Машинні коди і мову асемблера
13. Як працює статичний компілятор
14. Як працює інтерпретатор мови
15. Як працює інтерпретатор байт-коду
16. ЯК ПРАЦЮЄ компілятор JUST-IN-TIME (JIT)
17. Переваги та недоліки компілятора JIT
18. ДОДАТКОВА ІНФОРМАЦІЯ

Sun розробила динамічний компілятор нового покоління, що генерує принципово інший байт-код

Наша взаимовыгодная связь https://banwar.org/

Розроблена Sun технологія HotSpot дозволяє створювати інтерпретується байт-код, який виконується значно швидше двійкові програми! Чи можливо таке? Чому б і ні! Технологія HotSpot являє собою унікальну комбінацію віртуальної машини Java (JVM) і компілятора, яка до недавнього часу існувала тільки в лабораторіях. Її поширення, можливо, дозволить побити всі рекорди продуктивності, відомі на сьогоднішній день. Дана стаття знайомить читача з внутрішньою будовою динамічного компілятора Sun. Ви дізнаєтеся також, які програми HotSpot може виконувати швидше найшвидших компіляторів JIT. Крім того, проводиться порівняння технології HotSpot з її попередницями - стандартними віртуальними машинами, звичайними компіляторами і компіляторами just-in-time.

ВИХІДНА ТОЧКА: розігрівати ДВИГУНИ

Загальновідомо, що інтерпретується код працює повільніше скомпільованої. Прекомпіляції вихідного коду Java в стерпний байт-код економить час, який йде на перевірку синтаксичних конструкцій програми, проте в порівнянні з виконанням коду, обробленого компілятором інтерпретація коду віртуальною машиною Java все одно здійснюється значно повільніше. Тому, якщо технологія Java і забезпечує прийнятну продуктивність при виконанні компактних аплетів, про складні додатках цього вже сказати не можна.

Компілятор, що обробляє вихідний код "на льоту" (just-in-time compiler, JIT), дозволяє працювати на швидкостях, у багато разів перевищують можливості інтерпретатора. Істотна різниця відчувається навіть при роботі з інтерактивними додатками. Хоча JIT і поступається за продуктивністю заздалегідь скомпільовані кодом, проте він дозволяє значно розширити сферу застосування додатків Java. Однак додатків, що вимагають високої швидкодії, як і раніше не вистачає обчислювальної потужності. Якщо програма веде постійний діалог з користувачем або часто виконуються операції введення / виводу, з такою продуктивністю ще можна змиритися. Однак як тільки додаток стикається з трудомісткими операціями обробки графіки або з необхідністю виконання складних обчислень, продуктивність падає нижче допустимого рівня.

Основою розробленої Sun нової технології HotSpot є вбудований в віртуальну машину динамічний компілятор, який для більшості додатків працює так само швидко, як і заздалегідь скомпільований код (а може бути, і швидше). Технологія HotSpot повинна значно розширити рамки застосування Java (як для серверів, так і для клієнтських робочих станцій). При цьому зберігається основна перевага мови - переносимість. Випуск засобів підтримки HotSpot JVM для розробників був запланований корпорацією Sun на перший квартал нинішнього року; версія HotSpot JVM для користувачів повинна з'явитися влітку.

ПОЇХАЛИ! "І плавиться асфальт, протектор кип'ятити"

Динамічний компілятор HotSpot об'єднує в собі кращі риси JIT-компілятора й інтерпретатора. Така комбінація "два в одному" значно підвищує швидкість виконання коду. Безперечні переваги концепції динамічної компіляції базуються на дослідженнях, які проводилися протягом останніх 10 років в Стенфорді і університеті міста Санта-Барбара. За ці роки вдалося забезпечити технології достатню надійність. А поява HotSpot має сприяти сплеску її популярності. Крім динамічної компіляції в HotSpot прекрасно реалізовані ще два аспекти: "збірка сміття" і синхронізація.

"Прибирання сміття" і синхронізація

На жаль, для підвищення швидкості роботи додатків Java однієї оптимізації коду недостатньо. Для того щоб підвищити швидкодію, розширити функціональність і усунути помилки додатків, необхідно вдосконалити всі механізми. Найбільш важливий фактор, що впливає на продуктивність системи, - це якість реалізації процедур "збірки сміття" і управління потоками. Як показано на діаграмі (рис. 1), до 40% загального часу витрачається на виконання саме цих завдань. Цей малюнок досить повно відображає тенденції, що склалися. Важливо відзначити, що деякі програми фактично весь час витрачають на "складання сміття" і синхронізацію, в той час як у інших витрати на виконання даних завдань вкрай незначні. (Для побудови діаграми бралися усереднені значення.)

Вбудований механізм "збірки сміття", наявність якого є відмінну рису технології Java, значно полегшує програмування. Як відомо, він дає можливість уникнути непередбачених "витоків пам'яті", які буквально поглинають системні ресурси, якщо некоректно написана програма захоплює блок пам'яті і не звільняє його. Зрештою пам'яті виявляється недостатньо навіть для виконання базових функцій. Щоб виключити ймовірність виникнення подібної ситуації, і був розроблений механізм "збірки сміття". Однак його функціонування забирає процесорний час. У деяких додатках виділення і звільнення пам'яті відбувається настільки часто, що на "складання сміття" йде значно більше часу, ніж на виконання всього програми. В такому випадку оптимізація коду програми не грає практично ніякої ролі.

Ще одна процедура, що надає досить істотний вплив на продуктивність, - це синхронізація потоків. Потоки Java (одночасно виконуються сегменти коду) дозволяють домогтися максимальної гнучкості. Зокрема, вони дають можливість організувати введення / виведення через буфер, підвищуючи тим самим швидкість виконання програми. Механізм многопоточности дозволяє розробникам створювати серверні додатки, одночасно обслуговуючі безліч клієнтів. Однак витрати на синхронізацію можуть забирати до 20% процесорного часу. Більш того, оптимізація скомпільованої коду не здатна прискорити синхронізацію.

Крім динамічної компіляції технологія HotSpot надає вдосконалений метод збирання сміття, званий "складанням сміття різних поколінь" (generational garbage collection). Дослідження, що проводяться в даному напрямку, раніше вважалися суто академічними, але вже сьогодні їх результати знаходять широке застосування в мові Java. Ідея "збірки сміття різних поколінь" полягає в тому, що блоки пам'яті розподіляються і звільняються в хронологічній послідовності.

Поділ блоків пам'яті на різні "покоління" забезпечує дві основні переваги. По-перше, прибирання сміття виконується послідовно. Замість того щоб переглядати всю пам'ять за один прохід (що дуже сильно знижує продуктивність системи), механізм складання сміття аналізує лише невелике число блоків. Така технологія звільнення пам'яті дозволяє виконувати дану операцію частіше і з меншими тимчасовими втратами, а отже, зменшується і негативний вплив на продуктивність програми. Це особливо важливо при роботі з інтерактивними додатками, оскільки користувачі вважають за краще отримувати саме ту продуктивність, на яку вони розраховували, при цьому зовсім не жалуючи "навіжені" програми. Крім того, значно спрощується сам процес складання сміття.

В технології HotSpot вдосконалена і процедура синхронізації. У багатьох випадках операції, для реалізації яких раніше було потрібно кілька інструкцій, тепер виконуються однією командою. Таким чином, багатопотокові програми фактично не знижують загальної продуктивності.

Одночасне поліпшення механізмів збирання сміття і синхронізації дало можливість радикально підвищити швидкодію системи, навіть не вдаючись до оптимізації коду додатків. Однак дана стаття присвячена динамічної компіляції, тому, як то кажуть, повернемося до наших баранів.

Як працює динамічний компілятор

HotSpot включає в себе як динамічний компілятор, так і віртуальну машину, інтерпретує байт-код (рис. 2). На першому етапі віртуальна машина інтерпретує байт-код, отриманий на виході компілятора Java Compiler (JavaC). У міру його виконання профілювальник збирає інформацію про продуктивність і вибирає метод, який компілюватиметься. Скомпільовані методи зберігаються в кеші "рідних" машинних кодів. При черговому виклику методу використовується його версія, що зберігається у вигляді "рідного" машинного коду (якщо така існує). В іншому випадку проводиться повторна інтерпретація байт-коду. Функція "управління", проілюстрована на малюнку, є, по суті, командою непрямого переходу в пам'яті, яка вказує або на "рідний" код, або на інтерпретатор. (Загальний принцип роботи виглядає саме так, хоча конкретні деталі реалізації не розкриваються.)

Після першого завантаження байт-коду він виконується інтерпретатором. Профілювальник стежить за кожним методом, і якщо виявляється, що виконання будь-якого методу займає багато часу, HotSpot компілює і оптимізує його. При кожному наступному виклику цього методу виконуються вже "рідні" машинні інструкції, згенеровані компілятором.

Точно так же, як і в разі використання JIT, результати компіляції після закінчення роботи програми не зберігаються. Байт-код більш компактний, що дозволяє прискорити завантаження програми і зменшити необхідний обсяг пам'яті. Крім того, байт-код може бути перенесений на інші платформи і дає можливість застосовувати різні методи оптимізації. В даний час інформація, що дозволяє прискорити повторне виконання програми, не зберігається, хоча в майбутньому, цілком можливо, такий підхід буде реалізований.

Профілювальники і евристична компіляція

Найбільш цікавим з точки зору технології є вибір профілювальником методів, які повинні оптимізуватися. Сьогодні системи обходяться мінімальним набором евристичних алгоритмів, а досягнення штучного інтелекту практично не використовуються. Хоча подробиці виробники тримають в таємниці, ризикну припустити, що кандидатом на проведення оптимізації стає метод, час виконання якого перевищує певний поріг, скажімо, 70% від передбачуваного часу оптимізації. (Природно, для точного визначення порогу необхідні більш глибокі дослідження).

На щастя, згідно зі свідченнями співробітників Sun, слідувати цій методиці зовсім не обов'язково. Звичайно, досконалості немає меж, але в переважній більшості випадків вам навряд чи вдасться помітити будь-яку різницю у швидкодії програми. Втім, хто знає?

Ймовірно, з часом можна буде використовувати і більш ефективні евристичні методи. Але поки що жодна з компаній не збирається впроваджувати такі технології - в найближчі рік-два вони не бажають пов'язувати себе подібними обіцянками. Однак фахівці постійно тримають в полі зору таку можливість.

Переваги динамічної компіляції

Інтеграція компілятора й інтерпретатора дозволяє вирішувати завдання, недоступні для звичайного статичного компілятора, і в цьому її основна перевага. Зокрема, з'являється можливість виконання "оптимістичною" компіляції та використання інформації, доступної на етапі виконання програми, для "вбудовування" методів.

Оптимістична компіляція. Оскільки інтерпретатор завжди доступний для виконання байт-коду, динамічний компілятор HotSpot передбачає, що виняткові ситуації і інші складні для оптимізації випадки можна не враховувати. Якщо така ситуація все ж виникає, HotSpot може повернутися до інтерпретації байт-коду. У статичному компіляторі оптимізація, при якій враховуються всі незвичайні ситуації, являє собою дуже довгий і складний процес. Ігноруючи подібні ситуації, HotSpot може швидко генерувати оптимізований код для тих частин програми, виконання яких найбільш ймовірно. Така тактика дає величезний виграш, забезпечуючи значне збільшення продуктивності при порівняно невеликих витратах на оптимізацію.

Інформація етапу виконання. Ще одна важлива перевага динамічної компіляції - це можливість обліку інформації, яка стає відома лише на етапі виконання програми. І тут деталі реалізації тримаються в секреті. Однак неважко здогадатися, що якщо, наприклад, метод викликається в циклі 10 000 раз, то його необхідно оптимізувати. Якщо ж цикл виконується всього один раз, оптимізацію можна опустити і виконати зазначений метод за допомогою інтерпретатора. Оскільки статичному компілятору заздалегідь невідомо кількість проходів циклу, він не в змозі приймати подібних рішень.

Вбудовування методів. Одним з найбільш ефективних способів оптимізації є вбудовування (inlining) часто планування для. Замість того щоб витрачати час на виклик методу, його код копіюється безпосередньо в тіло викликає процедури і виповнюється так само, як якби він був там запрограмований. Чим компактніше метод, тим ефективніше вбудовування. Виконувати операції виклику і повернення для методу, що складається з одного рядка, нераціонально. На це піде вдвічі більше часу, ніж на його реальне виконання.

Використання вбудованих методів забезпечує колосальний виграш в продуктивності, але при цьому не можна забувати і про відповідне збільшення обсягу пам'яті, займаної програмою. Якщо кожен метод додатки буде розміщуватися в місці його виклику, обсяг коду зросте в п'ять - десять разів. Тому HotSpot оптимізує тільки критичні ділянки програми. Правило 80/20 свідчить, що 80% часу витрачається на виконання 20% коду. Якщо вбудовані методи будуть вибиратися саме з цих 20%, значного підвищення продуктивності вдасться досягти при збереженні прийнятних розмірів коду. В даному випадку інформація про час виконання не настільки важлива, оскільки HotSpot знає, де знаходяться ці критичні 20%.

До встраиванию методів потрібно підходити дуже обережно. Якщо розміри коду методу досить великі, то на виклик і повернення з процедури йде лише невелика частина загального часу виконання. В цьому випадку вбудовування явно не виправдовує себе. Технологія HotSpot, без сумніву, аналізує верхню межу розміру методу; в разі якщо вона виявляється перевищена, вбудовування вже не проводиться. (Однак подробиці, що стосуються цього процесу, не розголошуються.)

І нарешті, оскільки HotSpot виконує оптимістичну компіляцію, встраиванию піддаються тільки ті методи, ймовірність виконання яких найбільш висока. Таким чином, щоб не витрачати час на вирішення проблем, що виникають досить рідко, вони просто ігноруються. В результаті ви отримуєте максимальну продуктивність при мінімальних витратах на оптимізацію.

Критерії ефективності динамічної компіляції

У переважній більшості випадків HotSpot працює значно швидше компіляторів JIT, не кажучи вже про звичайну інтерпретації за допомогою JVM. Але іноді використання динамічного компілятора HotSpot, як і будь-який інший технології підвищення продуктивності, не дозволяє досягти найкращих показників. Зокрема, профілювальник може прийняти рішення про оптимізацію частини коду відразу після того, як вона була виконана в останній раз. Очевидно, що таких ситуацій уникнути неможливо. На щастя, вони виникають досить рідко.

Технологія HotSpot не надто пристосована і для обробки чисто обчислювальних додатків, в яких операція "збірки сміття" виконується нечасто, немає синхронізації потоків, а обсяг ініціалізації коду дуже малий. Як приклад такого додатка можна привести програму, перемножуються першу 1000 простих чисел і виводить результат на екран монітора. Хороший JIT-компілятор забезпечує в цьому випадку найвищу продуктивність, оскільки він не витрачає часу на аналіз, а виконує безумовну оптимізацію.

Крім того, HotSpot відмовляється досить якісно виконувати штучні тестові програми, такі як CaffeineMark. Оскільки подібні штучні додатки дуже сильно відрізняються від реальних, для визначення всіх оцінюваних в них ситуацій доведеться написати спеціальний компілятор, дуже швидко виконує тести, багато з яких ніколи не зустрінуться в реальних програмах (зокрема, оптимізацію порожнього циклу). У порівнянні з ним компілятор, що не оптимізує неохайно написаний код, буде виглядати не кращим чином, хоча насправді він більше пристосований до виконання реальних завдань. (Нещодавно Sun продемонструвала спеціально спроектований таким чином компілятор. Він прекрасно "оптимізував" непотрібні програмні конструкції, виконуючи їх код практично миттєво. Можливо, моя думка не збігається з загальноприйнятим, проте ризикну зауважити, що штучні тести дають лише дуже приблизне уявлення про реальну продуктивності. )

Будь-яка технологія підвищення швидкодії є вільною недоліків, тому питання полягає в тому, наскільки вона підходить для використовуваних вами додатків. У переважній більшості додатків "прибирання сміття" і синхронізація потоків грають далеко не останню роль, а код періодично повторюється. В цьому випадку HotSpot забезпечує дуже серйозне збільшення продуктивності.

HotSpot в порівнянні з "рідним" кодом

Проводячи порівняння динамічної компіляції з іншими способами обробки Java-коду, не слід забувати, що це всього лише різні способи виконання Java. Скептично налаштований читач напевно помітить: "Ну ладно, а як цей механізм працює в порівнянні з моїм улюбленим компілятором?" Уже сьогодні чаша терезів схиляється на користь HotSpot, а якщо взяти до уваги перспективи ... Sun прагне досягти рівня продуктивності оптимізованої програми на C, і якщо вірити заявам представників компанії, вона близька до цього, як ніколи.

На даний момент хороші JIT-компілятори не поступаються (а можливо, і перевершують) статичним компіляторам C ++, що обробляють об'єктно-орієнтовані програми (див. Статтю "Java і C ++: тест на швидкодію" в лютневому номері JavaWorld Росія). А HotSpot працює швидше компілятора JIT! Ми поки що ще не досягли продуктивності скомпільованих C-програм, але вже близькі до цього.

Не будемо забувати про те, що мова C ++ може використовуватися для створення не тільки об'єктно-орієнтованих додатків, але і дуже швидких програм, в яких не зустрічається об'єктно-орієнтована код. Сьогодні Java вже може позмагатися з C ++ в швидкості виконання об'єктно-орієнтованих програм. Однак оптимізація компілятора C ++ для роботи з кодом C, котрий використовує об'єктно-орієнтованих розширень, дозволяє виконувати додатки зі швидкістю для Java поки недосяжною. При цьому ускладнюється підтримка програм, але зате збільшується швидкодія.

ФІНІШ? НУ ЩО ВИ, ГОНКА ТІЛЬКИ ПОЧИНАЄТЬСЯ!

HotSpot - це перша працююча реалізація динамічного компілятора для мови Java. Коректність його роботи підтверджена випробуваннями. Зараз для того, щоб домогтися абсолютно оптимальної продуктивності, необхідно послідовно вдосконалювати технологію. Sun вважає, що вже в найближчі кілька років Java-програми зможуть виконуватися так само швидко, як і оптимізовані програми на C!

Це справді вражає. Якщо переносних незалежний код зможе випередити по продуктивності навіть оптимізований "рідний", це буде означати, що в найближчі кілька років на мові Java зможуть створюватися фактично будь-які додатки. Java перестане бути мовою написання аплетів!

ЯК ПРАЦЮЮТЬ Компілятори та інтерпретатори

В даному розділі наводиться історична довідка про компіляторах і інтерпретатора різних мов, а також про інтерпретатора байт-коду.

Машинні коди і мову асемблера

В кінцевому рахунку, комп'ютери здатні виконувати тільки обмежений набір інструкцій, які називаються машинними кодами. Машинні коди - це набір цифр, однозначно сприймається комп'ютером. Колись давним-давно програми заносилися в пам'ять комп'ютера за допомогою перемикання розташованих на передній панелі перемикачів, які формували певний набір цифр (інструкцій), які керують роботою комп'ютера.

Величезний крок вперед був зроблений, коли комп'ютер навчили транслювати команди, записані на мові асемблера. Ця мова повністю дублює машинні інструкції, але замість набору цифр завантажує в пам'ять комп'ютера відповідні їм мнемонічні коди (наприклад, "LDA"). Хоча між машинними та мнемонічними кодами і існує однозначна відповідність, прогрес полягав в тому, що тепер комп'ютер міг самостійно переводити програму на асемблері в машинні команди. На рис. 3 показано, як асемблерна команда LDA перетворюється в машинну команду 1378, регістру "A" присвоюється номер 00, а змінна N розміщується в пам'яті за адресою 1000. Даний приклад дуже умовно ілюструє те, що відбувається в дійсності, але тим не менш дає зрозуміти, яким чином інструкції асемблера переводяться в машинний код.

Як працює статичний компілятор

Наступним важливим етапом розвитку програмних технологій стала поява мов високого рівня, таких як C і Pascal. У цих мовах одна інструкція транслювалася відразу в кілька машинних команд. Процес трансляції інструкцій мови високого рівня в машинні коди називався компіляцією. Створення компіляторів переслідувало ту ж мету - полегшити людині читання програм, що розуміються машиною. Однак тепер людина працювала вже з мовою високого рівня: розміри коду істотно зменшилися, а машині було потрібно виконати значно більше операцій для трансляції програми в машинні коди.

Результати компіляції декількох вихідних файлів пізніше компонувалися в єдиний виконуваний модуль. Для цього необхідно було як мінімум об'єднати програму з попередньо відкомпілювалися функціями системних бібліотек. (Приєднання бібліотечних функцій може виконуватися і на етапі виконання програми. Такі бібліотеки називають динамічними - dynamically linked libraries, або DLL.)

Процес компіляції розбивається на чотири основні етапи: лексичний аналіз, граматичний розбір, генерацію коду і оптимізацію. На етапі лексичного аналізу компілятор виділяє в вихідному файлі окремі лексеми. Наприклад, в операторі if (myVal == 123) окремими лексемами є: "if", "(", "myVal", "==", "123", ")" і ".". На етапі граматичного розбору окремі лексеми об'єднуються в оператори. Якщо компілятор не може розпізнати сенс оператора, видається повідомлення про помилку. Якщо ж сенс оператора ясний, здійснюється перехід до наступного етапу - створення коду.

На етапі генерації коду оператори мови високого рівня перетворюються в машинні команди. (Іноді компілятор генерує інструкції мови асемблера, які потім переводяться до відповідних їм машинні коди. Втім, суть від цього не змінюється.) Після закінчення генерації машинних команд компілятор переходить до процедури оптимізації. Наприклад, результат виконання будь-якої інструкції з процесорного регістра переноситься в пам'ять. У той же час наступна команда знову завантажує це значення в регістр для виконання чергової операції. Компілятор розпізнає неоптимальний код і виключає зайві команди запису і читання.

Як працює інтерпретатор мови

Компілятор генерує дуже ефективний код, але для виконання ним своїх завдань потрібен додатковий час. Причому, чим вище рівень оптимізації, тим більше часу йде на компіляцію. Такий процес не викликає особливих труднощів при одноразової трансляції програми, але для початківців програмістів він стає справжньою мукою. Для того, щоб налагодити невеликий модуль, їм доводиться компілювати його по 30-40 разів. Настільки великі витрати вбивають будь-яке бажання писати програми.

Програми, написані на таких мовах, як Basic, виконуються в режимі інтерпретації. На відміну від компілятора, який повинен повністю странсліровать програму в машинні коди, перш ніж вона може бути запущена, інтерпретатор зчитує і виконує інструкції послідовно. При цьому кожна команда проходить повний цикл обробки. Спочатку аналізуються лексеми, потім виконується граматичний розбір, а після цього, не зберігаючи ніяких проміжних результатів, процесор відразу виконує машинні коди, в які перетворюється дана інструкція.

Командно-орієнтовані операційні системи (наприклад, DOS або CSH) є такими ж інтерпретаторами, які виконують обмежений набір інструкцій. Інтерпретатор в циклі аналізує інформацію, що вводиться команду, виконує її і переходить в режим очікування нової інструкції. Типовий інтерпретатор команд мови Basic працює аналогічним чином. Як ви вже напевно помітили, оптимізації результуючого коду не проводиться, тому інтерпретатор не відрізняється особливою ефективністю. Оскільки кожна інструкція виконується що називається "в лоб", результат однієї команди може бути збережений, тільки щоб витягти його наступною інструкцією. Крім того, "чистий" інтерпретатор послідовно розбирає і аналізує кожен рядок вхідного потоку. Це не так уже й погано, якщо ви виконуєте окремі команди або маленькі програми, проте швидкодія великого додатки в цьому випадку значно знижується.

Як працює інтерпретатор байт-коду

Двадцять років тому вчені Каліфорнійського університету в Сан-Дієго розробили мову UCSD Pascal, в якому були застосовані ті ж принципи, що і в сьогоднішньому Java. Програми дуже ефективно виконувалися за допомогою інтерпретатора байт-коду. На рис. 6 представлена ​​схема роботи інтерпретатора байт-коду.

Спочатку вихідний текст програми перетворюється в набір байт-кодів. Якщо вихідний текст написаний на Java, то трансляція виконується спеціальним "компілятором" Java -javac. Байт-коди є машинні команди неіснуючого в природі комп'ютера, званого віртуальною машиною. Після цього на реальній машині запускається інтерпретатор, що розуміє ці інструкції. Інтерпретатор байт-коду виконує аналізовані їм команди на реальному процесорі. Прикладом такого інтерпретатора є віртуальна машина Java (JVM). Лексичний і граматичний розбір вихідного тексту програми в цьому випадку проводиться на етапі формування байт-коду. Тому інтерпретатор байт-коду працює значно швидше інтерпретатора звичайного мови. Результуючий код займає значно менший обсяг пам'яті в порівнянні з повністю компільованою програмою. Але самим, мабуть, важливим є властивість переносимості байт-коду. Він може виконуватися на будь-якому комп'ютері, для якого створена віртуальна машина, здатна обробляти байт-код.

Однак навіть попередньо оброблений байт-код, перш ніж виконати, необхідно перетворити в машинні команди. При цьому накладні витрати на кожну окрему інструкцію невеликі, але при великій кількості інструкцій уповільнення стає вельми помітно. У складних додатках час затримки порівняно з часом виконання скомпільованого коду. Крім того, даний метод практично не дозволяє проводити оптимізацію. Таким чином, безсумнівним його перевагою є отримання компактного, машинно-незалежного коду, а недоліком - відносно низька швидкодія.

ЯК ПРАЦЮЄ компілятор JUST-IN-TIME (JIT)

Компіляція "на льоту" (just-in-time) дозволяє значно підвищити швидкість виконання байт-коду, оскільки компілятор перед виконанням перетворює його в машинні команди. В даному розділі коротко розглядається робота компілятора JIT.

Особливості компілятора JIT

Компілятор JIT спочатку транслює байт-код в машинні команди, а потім виконує їх. При цьому інтерпретації байт-коду на етапі виконання вже не відбувається. Даний процес представлений на рис. 7.

Машинні команди зберігаються лише в пам'яті і не записуються на диск. (Ось чому на малюнку вони знаходяться всередині пунктирного контуру.) Під час наступного запуску програми процес трансляції байт-коду в машинні інструкції повністю повторюється. В результаті байт-код зберігає свою переносимість, але виконується значно швидше в порівнянні зі звичайним інтерпретатором (в деяких випадках швидкодія може зростати в 50 разів). Як правило, такий швидкості виявляється цілком достатньо для роботи більшості інтерактивних додатків і програм, які здійснюють інтенсивний введення / виведення.

Переваги та недоліки компілятора JIT

Оскільки компілятор JIT обробляє не окремі команди, а відразу набір інструкцій, з'являється можливість виконувати оптимізацію. Наприклад, якщо яка-небудь змінна вже міститься в регістрі, компілятор JIT не завантажує її повторно. З цієї причини, а також внаслідок повної генерації виконуваного коду всієї програми технологія JIT дозволяє значно підвищити ефективність при багаторазовому виконанні одних і тих же ділянок коду.

З іншого боку компілятор JIT не забезпечує істотного виграшу при обробці програм з інтенсивним введенням / висновком (час, що витрачається на безпосереднє виконання команд, в цьому випадку настільки незначний, так що результати оптимізації стають практично непомітними). Не дуже вдало реалізований і процес "збирання сміття". Багато часу витрачається на обробку коду ініціалізації. Оскільки компілятор JIT оптимізує весь програмний код, значна частина витрат припадає на ініціалізаційний код та інші методи, що виконуються лише один раз. Нарешті, сама концепція JIT не дозволяє проводити повну оптимізацію. Адже чим "краще" компілятор, тим більше часу він витрачає на оптимізацію ділянок, які ніколи не будуть виконуватися.

ДОДАТКОВА ІНФОРМАЦІЯ