Чому на базі стека JVM базується реєстр Dalvik VM?

Мені цікаво, чому Sun вирішив зробити JVM на основі стека, і Google вирішив створити реєстр DalvikVM?

Я припускаю, що JVM насправді не може припустити, що певна кількість регістрів доступна на цільовій платформі, оскільки вона повинна бути незалежною від платформи. З цього приводу він просто відкладає розподіл регістра тощо для компілятора JIT. (Виправте мене, якщо я помиляюся.)

Тож хлопці з Android подумали: "Ей, це неефективно. Давайте відразу ж перейдемо до реєстру, заснованого на vm ..."? Але зачекайте, існує кілька різних пристроїв для Android, на яку кількість реєстрів націлив Дальвік? Чи жорстко кодуються коди Дальвіка для певної кількості регістрів?

Чи мають усі поточні Android-пристрої на ринку приблизно однакову кількість реєстрів? Або є перерозподіл реєстру, який виконується під час завантаження dex? Як все це поєднується?

Є кілька атрибутів VM на основі стека, які добре відповідають цілям дизайну Java:

1. Конструкція на основі стека робить дуже мало припущень щодо цільового обладнання (регістрів, функцій процесора), тому легко реалізувати VM на широкому спектрі обладнання.

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

Використання схеми, що базується на регістрі, ймовірно, означає, що генератор коду Дальвіка не повинен працювати так сильно, щоб створити продуктивний код. Працювання на надзвичайно багатій на регістри архітектурі або бідній на регістри, ймовірно, спричинило б дальвік Дальвіку, але це не звичайна мета - ARM - це архітектура, що знаходиться в середині дороги.

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

Я не можу знайти посилання, але я думаю, що Sun вирішив застосувати підхід байт-коду на основі стеку, оскільки це полегшує запуск JVM на архітектурі з невеликою кількістю регістрів (наприклад, IA32).

У Dalvik VM Internals з Google I / O 2008, автор Dalvik Ден Борнштейн наводить такі аргументи для вибору VM на основі реєстру на слайді 35 слайдів презентації :

Реєстраційна машина

Чому?

• уникати відправлення інструкцій
• уникайте зайвого доступу до пам'яті
• ефективно споживати потік інструкцій (вища семантична щільність на інструкцію)

та на слайді 36:

Реєстраційна машина

Статистика

• На 30% менше інструкцій
• На 35% менше одиниць коду
• На 35% більше байтів у потоці інструкцій
  • але ми отримуємо одночасно два

За словами Борнштейна, це "загальне очікування того, що ви могли б знайти, перетворивши набір файлів класу у файли dex".

Відповідна частина презентаційного відео розпочинається о 25:00 .

Існує також проникливий документ під назвою "Віртуальні розкриття віртуальної машини: Стійкі версивні регістри" Ши та ін. (2005) , який досліджує відмінності між віртуальними машинами на основі стека та реєстру.

Я не знаю, чому Sun вирішила створити JVM стек. Віртуальна машина Erlangs, BEAM реєструється на основі причин продуктивності. І Далвік також здається зареєстрованим через причини роботи.

З Pro Android 2 :

Dalvik використовує регістри в основному одиниці зберігання даних замість стека. Google сподівається виконати на 30 відсотків менше інструкцій.

А щодо розміру коду:

Dalvik VM приймає згенеровані файли класу Java та поєднує їх в один або кілька файлів Dalvik Executables (.dex). Він повторно використовує дублюючу інформацію з декількох файлів класу, ефективно зменшуючи потребу в просторі (нестиснений) наполовину від традиційного .jar-файлу. Наприклад, .dex файл програми для веб-браузера в Android становить близько 200 тис., Тоді як еквівалентна нестиснена версія .jar - близько 500 тис. Файл .dex будильника становить приблизно 50 кб і приблизно вдвічі перевищує його розмір у своїй .jar версії.

І як я пам’ятаю комп’ютерну архітектуру: кількісний підхід також приходить до висновку, що машина реєстрації працює краще, ніж машина на основі стека.