Почему основаны на стеке JVM и на базе виртуальных машин Dalvik?

Question

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

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

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

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

Answer 1

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

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

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

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

---

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

Answer 2

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

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

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

Почему?

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

и на слайде 36:

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

Статистика

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

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

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

Существует также проницательный документ под названием «Виртуальная машина, вскрытие: стек в сравнении с регистрами», автор Shi et al. (2005) , в котором рассматриваются различия между виртуальными машинами на основе стека и регистра.

Answer 3

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

С Pro Android 2 :

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

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

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

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