Страницы

Поиск по вопросам

вторник, 10 декабря 2019 г.

Виртуальная машина Java (или подобное), написанная на Java

#виртуальная_машина #java #embedded #jvm


Здравствуйте.
Недавно начал изучать виртуальные машины. Возник такой вопрос. Есть некоторые VM,
например, Monty, Squawk. Данные виртуальные машины частично или полностью написаны
на Java. Вот эта фраза меня немного в тупик загнала. (В силу недостатка знаний или
понимания, наверное).
Есть у нас виртуальная машина, написанная на низкоуровневых языках относительно Java
- C++, C, Assembler. Тут все ясно. Машина пишется для каждой платформы, привязываясь
к железу на низкоуровневых языках, для того чтобы интерпретировать псевдокод (байткод)
там, где установлена виртуальная машина. Таким образом достигается кроссплатформенность. 
То есть мы тратим ресурсы железа, для того чтобы поднять виртуальную машину на ней,
а затем генерировать машинный код для платформы на этапе исполнения. Из-за того, что
у нас есть промежуточный слой исполнение, программа, написанная на таких языках, проигрывает
компилируемым языкам.
Ну и собственно вопрос. Зачем писать виртуальную машину на основе другой, точнее
внутри другой. Есть у нас Java VM на устройстве, зачем нужно добавлять еще один слой
абстракции? Выходит, что мы пишем виртуальную машину на основе функционала, который
нам предоставляет уже существующая ВМ на устройстве. То есть таким образом мы, во-первых,
не можем сделать больше, чем предоставляет нам обрамляющая ВМ, к тому же используем
дополнительные вычислительные ресурсы ЭВМ.
Я правильно понимаю?
Хорошо, можно предположить, что это удобно в некоторых случаях, когда не требуется
весь функционал обрамляющей ВМ или же абстрагирование от реализации с целью упрощения
написания кода.   
Конечно, если компьютер предоставляет ресурсы, то можно сделать так, и разница практически
будет незаметна. НО обычно такие ВМ используются на мобильных, портативных устройствах.
Где здесь логика? Зачем добавлять дополнительный слой, ладно если бы это было бесплатно
относительно ресурсов, но ведь это ведет к большим затратам ресурсов, которых на мобильных
устройствах и так очень мало. 
Пожалуйста, объясните идею и преимущества. Может быть, я просто что-то неправильно
понимаю, поправьте, пожалуйста. 
Спасибо большое заранее.    


Ответы

Ответ 1



Squawk VM - не полностью написана на Java, а только часть. На вопрос, "зачем" это все существует, отвечает короткая статья в википедии: https://ru.wikipedia.org/wiki/Squawk. Я предполагаю, что Monty, которая также используется на мобильных устройствах, имеет тот же самый бэкграунд, что и squawk, только со своей спецификой.

Ответ 2



Похоже, что главная цель -- заставить конечного пользователя покупать все более мощные (и дорогие) устройства. Она никогда не формулируется явно, но органически следует из стремления большинства разработчиков получить всего побольше, побыстрее и с меньшими усилиями (кстати, все вышесказанное относится не только к IT).

Ответ 3



переносимость ВМ и ПО для нее между разными устройствами, в частности для запуска на Android и других устройствах без перекомпиляции: автор ВМ может самостоятельно контролировать степень подобия работы ПО на разных устройствах/ОС в т.ч. look&feel GUI интерфейсов потери скорости можно обойти бинарной трансляцией байткода myVM->JVM и встроенным в JVM JIT-компилятором в нативный код: контроль за работой приложений остается, при этом скорость исполнения стремится к скорости машинного кода (при хорошей реализации JIT) [backdoor] обновление ПО без ведома пользователя в обход системы безопасности Android: пользователю достаточно при установке VM один раз подтвердить права, а обновления байткода можно грузить хоть ежечасно и запускать втихую

Комментариев нет:

Отправить комментарий