Почему на основе стека JVM и регистров Dalvik VM?

99

Мне любопытно, почему Sun решила сделать JVM на основе стека, а Google решил сделать DalvikVM на основе регистров?

Я полагаю, что JVM не может действительно предполагать, что на целевой платформе доступно определенное количество регистров, поскольку предполагается, что она не зависит от платформы. Поэтому он просто откладывает выделение регистров и т. Д. До JIT-компилятора. (Поправьте меня если я ошибаюсь.)

Так что ребята из Android подумали: «Эй, это неэффективно, давайте сразу перейдем к виртуальной машине на основе регистров ...»? Но подождите, существует несколько разных устройств Android, на какое количество регистров нацелился Dalvik? Запрограммированы ли коды операций Dalvik для определенного количества регистров?

Все ли современные устройства Android на рынке имеют примерно одинаковое количество регистров? Или во время dex-загрузки выполняется перераспределение регистров? Как все это сочетается?

aioobe
источник
5
Было ли это решение Google сделать DalvikVM на основе регистров? Я думаю, что DalvikVM был реализован до того, как Google приобрела Android Inc.
RoboAlex
1
Вы конечно правы. (Хотя это не очень актуально для вопроса;)
aioobe

Ответы:

69

Есть несколько атрибутов виртуальной машины на основе стека, которые хорошо согласуются с целями разработки Java:

  1. Архитектура на основе стека делает очень мало предположений о целевом оборудовании (регистрах, функциях ЦП), поэтому легко реализовать виртуальную машину на большом разнообразии оборудования.

  2. Поскольку операнды для инструкций в основном неявны, объектный код будет меньше. Это важно, если вы собираетесь загружать код по медленной сетевой ссылке.

Переход к схеме на основе регистров, вероятно, означает, что генератору кода Dalvik не нужно работать так усердно, чтобы создать эффективный код. Работа на архитектуре с очень большим количеством регистров или без них, вероятно, помешает Dalvik, но это не обычная цель - ARM - это очень промежуточная архитектура.


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

Марк Бесси
источник
1
Хорошо, это интересно. Так предполагает ли DalvikVM какое-то минимальное количество регистров на целевом устройстве?
aioobe
1
Кроме того, я читал, что некоторые люди устанавливают Android на свои ноутбуки, поскольку это «легкая» ОС ... Это кажется плохой идеей, если ноутбук не ARM и, возможно, имеет архитектуру с множеством регистров?
aioobe
2
хорошо, я только что узнал, что байт-код dex определяется в терминах машины с бесконечным регистром, и когда дело доходит до эффективности, похоже, в основном это связано с объемом памяти.
aioobe,
1
Я не мог вспомнить, был ли Dalvik основан на бесконечном регистре или имел фиксированный размер регистрового файла. Если он бесконечен, то он будет оптимально работать на архитектурах, которые имеют «достаточно» регистров для любого кода, который вы запускаете.
Марк Бесси,
Более подробное объяснение можно найти здесь: markfaction.wordpress.com/2012/07/15/…
noego
31

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

В Dalvik VM Internals от Google I / O 2008 создатель Dalvik Дэн Борнштейн приводит следующие аргументы в пользу выбора виртуальной машины на основе регистров на слайде 35 слайдов презентации :

Зарегистрировать машину

Зачем?

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

и на слайде 36:

Зарегистрировать машину

Статистика

  • На 30% меньше инструкций
  • На 35% меньше кодовых единиц
  • На 35% больше байтов в потоке инструкций
    • но мы можем потреблять по два за раз

По словам Борнштейна, это «общее ожидание того, что вы можете найти, преобразовав набор файлов классов в файлы dex».

Соответствующая часть презентационного видео начинается в 25:00 .

Существует также содержательная статья Ши и др. Под названием «Столкновение виртуальных машин: стек против регистров». (2005) , в котором исследуются различия между виртуальными машинами на основе стека и регистров.

поток
источник
13

Я не знаю, почему Sun решила сделать стек JVM. Виртуальная машина Erlang, BEAM основан на регистрах из соображений производительности. И Dalvik, похоже, также основан на регистрах из-за соображений производительности.

Начиная с версии Pro Android 2 :

Dalvik использует регистры как единицы хранения данных, а не стек. В результате Google надеется выполнить на 30 процентов меньше инструкций.

А что касается размера кода:

Dalvik VM берет сгенерированные файлы классов Java и объединяет их в один или несколько файлов Dalvik Executables (.dex). Он повторно использует повторяющуюся информацию из нескольких файлов классов, эффективно уменьшая потребность в пространстве (несжатом) вдвое по сравнению с традиционным файлом .jar. Например, файл .dex приложения веб-браузера в Android составляет около 200 КБ, тогда как эквивалентная несжатая версия .jar - около 500 КБ. Файл будильника .dex составляет около 50 КБ, что примерно вдвое больше в его версии .jar.

И насколько я помню, компьютерная архитектура: количественный подход также пришел к выводу, что регистровая машина работает лучше, чем машина на основе стека.

Йонас
источник
2
Если бы мне пришлось угадывать, я бы сказал, что Sun решила создать стек JVM, потому что его проще реализовать, чем регистровую машину. (Но с нетривиальной ценой производительности, как здесь отмечено.)
Мейсон Уиллер
Я не могу найти ссылку, но я думаю, что Sun решила использовать метод байт-кода на основе стека, потому что он упрощает запуск JVM на архитектуре с низким регистром.
Flow
1
Для аппаратной ISA, да, регистровые машины победили. По сути, каждый ЦП / микроконтроллер - это регистровая машина, потому что все остальное по сравнению с ним - отстой. Некоторые из них имеют очень мало регистров, например, просто аккумулятор и, возможно, один или два указателя или индексных регистра, но это все же больше похоже на регистровую машину в смысле теории вычислений. Но мы говорим о виртуальных машинах, которые интерпретируются , поэтому «регистровый файл», если он есть, на самом деле будет в памяти. Если вы не компилируете JIT в машинный код. Причины того, что reg работает быстрее стека, очень разные.
Питер Кордес