Почему JVM является стековой и основанный на регистре VM Дальвика?
Мне любопытно, почему Sun решал сделать JVM стековой, и Google решают сделать DalvikVM основанным на регистре?
Я предполагаю, что JVM не может действительно предположить, что определенное число регистров доступно на целевой платформе, так как это, как предполагается, независимо от платформы. Для этого это просто откладывает выделение регистра и т.д. к JIT-компилятору. (Исправьте меня, если я неправ.)
Таким образом, парни Android думали, "эй, это неэффективно, позволяют нам пойти для регистра базирующийся vm сразу же..."? Но ожидайте, существует несколько различных устройств на базе Android, для какого количества регистров Дальвик предназначался? Коды операций Дальвика hardcoded для определенного числа регистров?
Все текущие устройства на базе Android на рынке имеют о том же количестве регистров? Или, существует ли перераспределение регистра, выполненное во время dex-загрузки? Как все это совмещается?
1 ответ
Есть несколько атрибутов виртуальной машины на основе стека, которые хорошо согласуются с целями разработки Java:
Дизайн на основе стека дает очень мало { {1}} предположения о целевом оборудовании (регистры, функции ЦП), поэтому легко реализовать виртуальную машину на широком спектре оборудования.
Поскольку операнды для инструкций в значительной степени неявны, код объекта будет иметь тенденцию быть меньше. Это важно, если вы собираетесь загружать код по медленной сетевой ссылке.
Переход к схеме на основе регистров, вероятно, означает, что генератору кода Dalvik не нужно работать так усердно, чтобы создать эффективный код. Работа на архитектуре с чрезвычайно большим количеством регистров или без них, вероятно, помешает Dalvik, но это не обычная цель - ARM - это очень промежуточная архитектура.
Я также забыл, что первоначальная версия Dalvik вообще не включала JIT. Если вы собираетесь интерпретировать инструкции напрямую, то схема на основе регистров, вероятно, лучше всего подходит для интерпретации.