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

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

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

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

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

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

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

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

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

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

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

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

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

Зачем?

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

и на слайде 36:

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

Статистика

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

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

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

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

Я не знаю, почему 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.

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