динамическая загрузка Dex файла в Dalvik

[dr_klm]

В общем и с явовской виртуальной машиной вышло по сценарию -- "хотели как лучше, а получилось -- как всегда." ;-) Вроде бы делали универсальный байткод, который write once, run anywhere... Сделали. Но теперь неймется компании Google, которая мало того, что написала для Явы новую виртуальную машину, да еще к тому-же и совершенно другой архитектуры.

Большинству, конечно, все равно, они свои программы перекомпилируют специальным гуглевским компилятором (который из обычных Java class files делает Dalvik-овские dex файлы). А что делать нам, несчастным писателям компиляторов ? ;-)

Но мало того, то байткод другой архитектуры. Еще и загружать динамически его приходится по-новому. И не просто по-новому, оказывается сам этот байткод Dalvik загрузить непосредственно не может, только из zip архива... В общем, грабли на граблях.

Ну вот я вроде разобрался. Пишу, чтобы зафиксировать. Вам это, скорее всего, будет не интересно. ;-)


Итак, возьмем программу Hello.java с одним единственным методом hello, который очевидно что делает. Задача в том, чтобы загрузить этот файл в Андроид динамически, непосредственно в двоичном виде.

Тоесть загрузить нужно Вот этот zip файл, созданный командой:

javac Hello.java && \
dx --dex --output=Hello.zip Hello.class && \ 
adb -e push Hello.zip /data/local

Чтобы это сделать, нужна вот такая программа SayHello.java, которая компилируется и работает вот так:

javac SayHello.java && \ 
dx --dex --output=SayHello.zip SayHello.class && \ 
adb -e push SayHello.zip /data/local \ 
adb -e shell dalvikvm -classpath /data/local/SayHello.zip SayHello
Note: SayHello.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
43 KB/s (2034 bytes in 0.045s)
Hi ! Im' your "Hello World" loader !
First, I'm hooking the DexFile class...Good.
Second, I'm getting hold of its constructor...Good.
Third, I'm instantiating the DexFile object on "/data/local/Hello.zip"...Good.
Fourth, I'm getting to its loadClass method...Good.
Fifth, loading Hello class from the loaded dex...Good.
Sixth, getting hello method of Hello class...Good.
Seventh, invoking the hello method:
Hello WORLD !
Done. Easy, isn't it ? ;-)

Ну не жуть ли ? ;-)


Так что, наступает эра многоплатформенных компиляторов в явовские байткоды со всеми вытекающими "прелестями". Да, явовский байткод не очень оптимален в плане используемого пространства, но неужели такая оптимизация, всего-лишь в несколько раз, стоила того ? И все равно-ж, гады, в процессе загрузки этого .zip с файлом .dex (вызов конструктора DexFile), они докомпилируют его в "оптимизированный" байткод в формате .odex, который еще хранят в отдельном файле.

Вот такая вот бессмысленная политика (ибо по-другому мне это сложно объяснить). Нет, для меня это, конечно, выгодно. Я то думал проект уже закончен. А тут опа, появляется возможность переписать все заново (с сохранением старого, проверенного и удобного API). Типа раз, и снова в девках. ;-) Хорошо, но бессмысленно.

По-хорошему нужно было спрятать свой dalvik подальше (как implementation detail, раз уж они верят, что именно такой подход даст им performance edge), включить в стандартную поставку перекомпилятор dx в прозрачном режиме и пройти явовский testsuite.

Comments

[(Anonymous)]

ваш проект заключается в написании компилятора? а какого, если не секрет?

[dr-klm.livejournal.com]

Проект называется JEL (http://www.gnu.org/software/jel/), он довольно таки старый. Однако, несмотря на это, поддерживается, прекрасно работает и широко используется.

Сейчас я пытаюсь понять -- нужно для него писать Dalvik backend или нет... Для приложений в Андроид такой мини-компилятор очень бы пригодился. Но переписывать кодогенератор -- занятие не из легких... Тем более, под другую архитектуру... Хотя, все возможно, принципиальных проблем нет, стек в регистрах запросто эмулируется.

К.Л.М.

[gegmopo4.livejournal.com]

С выходом Java6, в которой появилась поддержка скриптинга, нужда в JEL резко уменьшилась.

Например, в Open Galaxy Viewer (http://sourceforge.net/projects/ogv/) выражения используются для вычисления пользовательских столбцов, фильтров и т.п. Я замерил время -- и все столбцы сделал динамически вычисляемыми (толко оптимизировал специальный случай для простейших выражений вида tech.drive). Прекомпилированные выражения JavaScript вычислялись где-то вдвое медленнее нативных жавовских, а оптимизированные вообще не отличались (в пределах погрешности). util.Evaluator -- сам вычислитель, gui.dialogs.EditColumn -- форма редактирования, с блекджеком и шлюхами примитивной подсветкой синтаксиса и деревом свойств.

[dr-klm.livejournal.com]

API javax.script на то и javax, что присутствует не во всякой Java платформе. Кроме того, нужен же еще, собственно, и движок скрипта, который может быть, а может и не быть...

JEL -- это один self-contained .jar файл, на 35k.

Так что может, в каких-то случаях и уменьшилась, но все равно использование javax ведет к привязке к конкретной Java платформе и установленным extensions. В случае использования JEL, достаточно просто забросить .jar в проект и всё.

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

К.Л.М.

[gegmopo4.livejournal.com]

Насчёт производительности я не сомневаюсь, что JEL обгоняет во всех случаях. Но не везде эта разница существенна. Кроме JavaScript есть реализации этих интерфейсов ещё для десятков языков, на любой вкус (кроме того, они предоставляют свой собственный интерфейс, так что можно обойтись без javax.script), некоторые возможно и меньше 35Кб (но это интерпретаторы). В Андроиде должна быть скриптовая машина.

Так что область востребованности JEL сильно сузилась. Хм-м-м, может попробовать использовать в OGV? Текущие потребности удовлетворяет, +5% размера допустимо. Нет, универсальность и расширяемость, пожалуй, важнее.

[dr-klm.livejournal.com]

Ну конечно, по сравнению с тем временем, когда JEL только только появилась и была монополистом в соответствующем сегменте рынка (одним из первых third-party компиляторов в байткод JVM, между прочим), уровень востребованности JEL только сузился, если для Вас это так важно утвердить. Сузился в том смысле, что появились другие продукты, пытающиеся решать ту-же задачу.

Но не нужно забывать, что проекту уже 12 лет.

Тем не менее, эта библиотека очень даже востребована и актуальна по сей день. В первую очередь, за счет малого размера, простоты и более универсальной доступности на различных Java платформах. Причем, не обязательно использовать язык JEL, я знаю народ, который выбрасывает парсер и цепляет JEL в качестве кодогенератора.

К.Л.М.

[gegmopo4.livejournal.com]

Ну так мы вроде ни в чём и не расходимся во мнениях. ;)

Как минимум, сделать компилятор в Далвик -- интересная задача. А значит, стоящая. Я делал компиляторы и для менее осмысленных вещей.

[dr-klm.livejournal.com]

Задача интересная. Но хорошо-бы, перед тем как делать, узнать "политику партии". То-ж можно возиться возиться, а они вместо того, чтобы стандартизовать (ну, или хотя-бы заморозить в каком-то виде) описание байткода dex, возьмут и включат перекомпилятор в стандартную библиотеку. А гоняться за постоянно изменяющимся (возможно, без сохранения совместимости) промежуточным форматом -- то еще удовольствие. Особенно при наличии перекомпилятора на каждом устройстве, который сделает такую погоню ненужной.

Вот Вы знаете, что они там себе в Гугле думают ? Я лично твердого ответа по поводу их дальнейших планов насчет dalvik не нашел... Они таки собираются делать fork байткода, или таки сделают свою библиотеку (в т.ч. и класс ClassLoader) полностью совместимой с явовской ?

К.Л.М.