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

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

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

Итак, ребята из Android подумали: "Эй, это неэффективно, отпустите для регистрации на основе vm сразу..."? Но подождите, есть несколько разных устройств для Android, какое количество регистров делало цель Dalvik? Являются ли кодеки Dalvik жестко закодированы для определенного количества регистров?

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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

Почему?

избежать отправки команды

избегать ненужного доступа к памяти.

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

и на слайде 36:

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

Статистика

На 30% меньше инструкций

На 35% меньше единиц кода

35% больше байтов в потоке команд
но мы можем потреблять два раза за раз

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

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

Ответ 3

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

Из Pro Android 2:

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

И в отношении размера кода:

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

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