Перекомпиляция J2ME в Native, Теорию обсудили. Кто-бы еще реализовал. Поделиться Опции

[DmT]

Для чего перекомпилировать Java в Elf:
Как работают большинство виртуальных машин на стадии выполнения кода: загружают код методов класса, и затем из него создают новый код, машинный(нативный). Это называется JIT(Just in time) компиляция. То есть байт-код переводится в нативный код. Ну а нативный код уже выполняется процессором реальной машины.
Но есть и другой вариант: байт-код НЕ переводится в машинный код. Вместо этого при выполнении каждой инструкции байт-кода вызывается функция-обработчик. Это называется интерпритацией.
Интерпритация намного медленнее JIT компиляции, но при этом требует намного меньше памяти, что актуально во встраиваемых системах, типа телефона.

Смысл java to elf в том, что ресурсоемкий процесс JIT компиляции будет производиться ЗАРАНЕЕ, то есть на компьютере. Ну и по сути это уже не "JIT" а "перекомпиляция".

Если до сих пор не поняли... Речь не идет о языках программирования, в частности Java или С. То есть для того о чем мы говорим нам не нужны исходные коды приложения, которое мы будем перекомпилировать. Нам нужен конечный продукт - архив jar, внитри которого набор классов.
JAR -> j2elf -> ELF

Одноко конкретно мало кто представляет, что же из себу представляет перекомпиляция. Даже про себя могу сказать, что хоть я и неплохо ориентируюсь в этом, до конца не представляю весь механизм перекомпиляции.
Уважаемые разработчики, предлагаю это обсудить. А может быть даже кто-то возьмется реализовывать.

У JVM инструкций около 200.
JVM - стек-ориентированная, ARM - регистр-ориентированная.
Ну с этим я полагаю справиться можно.
Далее зоны с вероятными исключениями: на яве указываются ввиде таблицы. На ARM вот уж не знаю как.(?)
Все поля класса вынесены в отдельную область class файла. Методы - соответственно тоже, причем методы разделены, а это частично избавляет нас от гемора с импортами/экспортами.
Еще одна проблема - сборщик мусора(далее GC). Он должен проверять все ссылки на объекты и сверять с множеством изначальных объектов. Если на какой-либо объект более не существует ссылки в памяти - удалять этот объект. На словах просто, а на деле не очень. Не могу четко представить механизм перебора и отсеивания ссылок в стеке (отсеивание нужно, чтобы не перепутать объекты и примитивы(ведь значение ссылки объекта запросто может совпасть со значением примитива)). То есть тут либо как то по особенному организовывать сам стек(вводит идентификатор типа перед значением), либо хранить в GC множество указателей на ссылки на объекты, либо ...?
Еще есть такая вещь как наследование(в купе с полиморфизмом и т.д. Жду ваших предложений.

Обратить внимание на красные вопросы.

Сообщение отредактировал DmT - 25.4.2010, 8:14

[motoprogger]

На ARM вот уж не знаю как

Применительно к ARM - даже примерно не понимаю, о чём речь

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

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

[DmT]

Применительно к ARM - даже примерно не понимаю, о чём речь

Речь о том, как будет выглядеть на ARM конструкция

Код

try
{
    ...
}
catch(...)
{
    ...
}

Очень надеюсь, что стек JVM мы будем эмулировать не машинным стеком

А в чем собственно причина нежелания натифицировать стек? После генерирования нативных инструкций зачем нам придерживаться стандарта JVM?

[motoprogger]

как будет выглядеть на ARM конструкция

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

А в чем собственно причина нежелания натифицировать стек?

В том, что машинный стек процессора рассчитан исключительно на один тип данных и не имеет собственного деления на кадры стека

После генерирования нативных инструкций зачем нам придерживаться стандарта JVM?

Хорошо, если отказаться от возможности загрузки внешних классов, мы получаем возможность:
1) Представить каждый Java-объект в виде структуры, содержащий ссылку на таблицу методов класса, все примитивы объекта и ссылки на другие объекты
2) Представить каждый кадр стека в виде структуры, содержащей примитивы и ссылки на объекты
При этом заранее известно множество таких структур и смещения, по которым в них располагаются ссылки на объекты, далее имхо очевидно... а если отказаться от Reflection API, то можно из классов поудалять ещё и имена методов и полей, оставить только структуру со статическими членами и таблицы методов (собственная таблица класса и по одной для каждого реализуемого интерфейса)

[Andy51]

DmT, закончил бы ты сначала эмуль эльфов..

[baat]

Andy51, зачем меня цитировать? :)

[Fenja]

Думаю никому не надо объяснять, для чего перекомпилировать Java в Elf.

Думаю надо. Ява ООП, а С функциональное?
И получиться в каждом эльфе будет ява приложение + мини ява машина?

[DmT]

DmT, закончил бы ты сначала эмуль эльфов..

Так, чтобы прояснить ситуацию: Я (я - это такой человек, который сейчас пишет это сообщение. Который скрывается под ником DmT) НЕ собираюсь в ближайшее время переключаться на Java2Elf. Я просто вдруг вспомнил про небезызвестного om2804, которому и принадлежала идея, которую он высказал еще год назад:

om2804 (23:21:55 23/02/2009)
я тут начал формат class потихоньку ковырять
om2804 (23:22:07 23/02/2009)
class to elf бы сделать :)

Вспомнил, и решил просто подготовить информационную базу на будующее.

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

[baat]

Fenja, ну на еп2 so есть допустим, не обязательно в каждый пхать, единственное, что большество кода будет на асме, поєтому хз... может в патче, вроди отдельного єльфпака проще будет, с отдельным типом файлов...

п.с. интересно как там тулбар, и вин-первоопрельский розыгрыш))) надеюсь java->jelf очередным не станет)))

[DmT]

Думаю надо. Ява ООП, а С функциональное?
И получиться в каждом эльфе будет ява приложение + мини ява машина?

А. Хорошо. Раз уже не перввый человек введен в заблуждение,
Если говорить просто и в двух словах:
Речь не идет о языках программирования, в частности Java и С. То есть для того о чем мы говорим нам не нужны исходные коды приложения, которое мы будем перекомпилировать. Нам нужен конечный продукт - архив jar, внитри которого набор классов.

Как работают большинство виртуальных машин на стадии выполнения кода: загружают код методов класса, и затем из него создают новый код, машинный(нативный). Это называется JIT(Just in time) компиляция. То есть байт-код переводится в нативный код. Ну а нативный код уже выполняется процессором реальной машины.
Но есть и другой вариант: байт-код НЕ переводится в машинный код. Вместо этого при выполнении каждой инструкции байт-кода вызывается функция-обработчик. Это называется интерпритацией.
Интерпритация намного медленнее JIT компиляции, но при этом требует намного меньше памяти, что актуально во встраиваемых системах, типа телефона.

Смысл java to elf в том, что ресурсоемкий процесс JIT компиляции будет производиться ЗАРАНЕЕ, то есть на компьютере. Ну и по сути это уже не JIT- а перекомпиляция.

[motoprogger]

Ну и по сути это уже не JIT- а перекомпиляция.

По сути это не JIT, а AOT
Предположим, само приложение не так уж и сложно перекомпилировать в исполняемый код. На самом деле. А как быть со стандартными классами - где ты столько исполняемого кода разместишь? А как быть с JNI - ему практически полностью структуры данных класса нужны, плюс структуры, связывающие байткод с нативным.
У меня есть несколько иное предложение. В качестве первой стадии - это будет загрузка явой so-файлов из jar-архива приложения и подгрузка JNI-функций из них. В качестве второй стадии - перекомпиляция каждого класса в отдельный so (или всего приложения в один so, не столь важно), а затем - перекомпиляция всех классов таким образом, что все методы в них объявлены как нативные (и размещены в этом so, активно обращающемся к функциям JVM). Исполняемого байткода в классах в итоге не останется. У кого-нибудь есть желание реализовать нормальный JNI на P2K?

[DmT]

По сути это не JIT, а AOT

Пожалуй да.

А как быть со стандартными классами - где ты столько исполняемого кода разместишь?

Конкретнее в чем проблема?

У меня есть несколько иное предложение.

Интересно, но только там где в JVM JNI реализован. На встраиваемых система с JVM - очень сомневаюсь.
А не на встаиваемых - и так весело работает JIT.

[DmT]

Спасибо motoprogger за находку:
http://gcc.gnu.org/java/
GCJ is a portable, optimizing, ahead-of-time compiler for the Java Programming Language. It can compile Java source code to Java bytecode (class files) or directly to native machine code, and Java bytecode to native machine code.
Compiled applications are linked with the GCJ runtime, libgcj, which provides the core class libraries, a garbage collector, and a bytecode interpreter. libgcj can dynamically load and interpret class files, resulting in mixed compiled/interpreted applications. It has been merged with GNU Classpath and supports most of the 1.4 libraries plus some 1.5 additions.

GCJ работает с arm, cобирает в ELF формат.

Посути большую часть того, что необходимо сделать уже реализовано в этом проекте. Нам осталось только собрать libgcj для нашей платформы. И добавить в EP2 совместимость с этими эльфами.

[Andy51]

DmT, я так полагаю, что проблема "всего лишь" в том, чтобы переписать ВЕСЬ J2ME API в C++ и слинковать со ВСЕМИ нативными функциями в прошивке, так?

[G-XaD]

Перечитал первый пост, но так и не нашел ответа на вопрос "Зачем перекомпилировать j2me приложения в эльф?"

[baat]

G-XaD, скорость и многозадачность...

[motoprogger]

DmT, я так полагаю, что проблема "всего лишь" в том, чтобы переписать ВЕСЬ J2ME API в C++

Не надо его туда переписывать. При чём здесь вообще C++?
Нужно извлечь весь байткод из прошивки, скомпилировать gcj в нативный, связать с нативными методами классов J2ME, имеющимися в прошивке, и собрать из всего этого свою версию libgcj. Ну и подправить функцию инита приложения из libgcj под другую ОС )

Перечитал первый пост, но так и не нашел ответа на вопрос "Зачем перекомпилировать j2me приложения в эльф?"

Перепиши пару-тройку эльфов на J2ME - поймёшь ценность обратного преобразования

Добавлено позже (17.5.2010, 2:23):

И добавить в EP2 совместимость с этими эльфами.

Насколько я понял, EP2 уже поддерживает shared-либы, а больше ничего не надо

[G-XaD]

G-XaD, скорость и многозадачность...

Думаю, размер эльфа + libgcj на выходе будет слишком большим чтобы вообще запускаться.

Перепиши пару-тройку эльфов на J2ME - поймёшь ценность обратного преобразования

Зачем писать на яве если можно на Си/С++? Явы я толком то и не знаю, точнее никогда не писал :)

Насколько я понял, EP2 уже поддерживает shared-либы, а больше ничего не надо

ЕП2 переваривает только эльфы обработанные постлинкером, там вроде особый формат (по крайней мере переделан вызов импортируемых функций)

[motoprogger]

Зачем писать на яве если можно на Си/С++? Явы я толком то и не знаю, точнее никогда не писал :)

Я именно про различие в работе эльфов и Java-приложений - вышеупомянутые

скорость и многозадачность...

Думаю, размер эльфа + libgcj на выходе будет слишком большим чтобы вообще запускаться.

Размер эльфа большим точно не будет. Размер libgcj определяется тем, какие классы мы в неё включаем. В прошивку же помещаются классы J2ME и интерпретирующая JVM? А из libgcj мы можем исключить интерпретацию за ненадобностью

ЕП2 переваривает только эльфы обработанные постлинкером, там вроде особый формат (по крайней мере переделан вызов импортируемых функций)

Тогда больше склонен думать, что придётся libgcj доводить под такое дело. Кстати, импорт из либ функций, находящихся в основном эльфе, у нас, я так понимаю, не только не поддерживается, но и не ожидается?

[baat]

motoprogger, вопрос, а смогут ли два таких эльфа-явы получить доступ к одному и тому же классу или методу ж2ме? и возможно ли к ним без написание собсвенной машины использовать готовую явовскую?

[Andy51]

При чём здесь вообще C++

Я подозреваю, что результирующий код строится по сипипишным конвенциям, наименования как минимум.

Нужно извлечь весь байткод из прошивки, скомпилировать gcj в нативный, связать с нативными методами классов J2ME, имеющимися в прошивке, и собрать из всего этого свою версию libgcj.

Опять же, "всего лишь". Удачи Безумству храбрых поём мы славу...

Кстати, импорт из либ функций, находящихся в основном эльфе, у нас, я так понимаю, не только не поддерживается, но и не ожидается?

Да, EP2 подразумевает исключительно иерархическую схему организации объектов, сверху-вниз.

[DmT]

Да, EP2 подразумевает исключительно иерархическую схему организации объектов, сверху-вниз.

Да не так уж трудно и добавить поддержку импортов в иерархически-независимой системе объектов.

[motoprogger]

а смогут ли два таких эльфа-явы получить доступ к одному и тому же классу или методу ж2ме?

Проблема со статическими объектами, подозреваю, будет. С динамическими - не должно быть.

и возможно ли к ним без написание собсвенной машины использовать готовую явовскую?

Ни собственная, ни готовая не понадобится, всё будет откомпилировано в нативный

[CrayZor]

Портировал кто бы qt либы чем думат как перегонят яву в натив код...

[DarkCoder]

У нас же на телефоне ОС основана на событиях. И как java код будет работать на событиях, ведь он вроде не предназначен к такому извращению.

[Fenja]

Портировал кто бы qt либы

зачем?

[CrayZor]

Портироват проги просто под эту либы...

[motoprogger]

И как java код будет работать на событиях, ведь он вроде не предназначен к такому извращению.

Я, конечно, не очень в теме, но вроде у нас пробегали эльфы с поточным выполнением, нет?
И вроде у родной JVM телефона отдельная задача ОС, так что, я так понимаю, можно в рамках этой задачи сделать поточное выполение нашего кода. Насчёт работы на событиях - для интерпретируемой Java, конечно, не проблема (у AFW есть событие типа "простой (idle)"?), а для компилируемой - потребовала бы серьёзных изменений в компиляторе

[DarkCoder]

Я, конечно, не очень в теме, но вроде у нас пробегали эльфы с поточным выполнением, нет?

Я таких в живую не видел, но ...
В проекте Andy51 Aegis есть т.н. task'и. Вот это то что нужно. Ждёмс релиз.

[Andy51]

CrayZor,

можно в рамках этой задачи сделать поточное выполение нашего кода

Тогда это уже задача для патчинга, а не для эльфов

у AFW есть событие типа "простой (idle)"?

Нет

Я таких в живую не видел

Есть 1) Matrix 2) Aegis 3) vNES
Сейчас вообще не до ковыряний, но работаю над подготовкой релиза патча на таски как появляется немного времени

[motoprogger]

Кстати, нашёл ещё одну интересную вещь: http://jcvm.sourceforge.net/
Пока не тестировал, в отличие от gcj (который на i386 работает очень даже успешно, по крайней мере, с теми классами, для работы с которыми не предполагается использовать Reflection API. Если включать информацию Reflection API в исполняемый файл, по объёму её получается чуть ли не больше, чем кода. Насколько помню, в J2ME нет Reflection)

[DarkCoder]

который на i386 работает очень даже успешно, по крайней мере, с теми классами, для работы с которыми не предполагается использовать Reflection API

Это что уже схема испытывалась на телефоне?

[DmT]

Это что уже схема испытывалась на телефоне?

Ты абсолютно не разбираешься в предметнойй области. Тебе русским языком написали i386.

[motoprogger]

все классы из явы

Эм, в яве есть какой-то фиксированный набор классов? Во новость ))
Вот конкретная реализация Java уже связана с набором стандартных классов, которые нам нужно извлечь и "тупо" откомпилировать )

[DmT]

которые нам нужно извлечь

это можно сделать из эльфа прошивки E1

[DarkCoder]

Ты абсолютно не разбираешься в предметнойй области.

Конечно не разбираюсь. просто я i386 попутал с E398.

[motoprogger]

это можно сделать из эльфа прошивки E1

Там J2ME классы могут быть немного иначе, по сравнению с целевым телефоном, привязаны к нативным методам, да и нативные методы могут не найтись по сигнатурам. Так что ещё вопрос )

[DmT]

Там J2ME классы могут быть немного иначе, по сравнению с целевым телефоном, привязаны к нативным методам, да и нативные методы могут не найтись по сигнатурам. Так что ещё вопрос )

Сомневаюсь, но даже если это так, можно попробовать найти способ поиска классов в прошивке. наверное там что-нибудь примитивное, например, таблица указателей.

[Andy51]

DmT, ау, а про Медузу уже забыли?
Проект Медуза

[DmT]

Andy51,
Ну, мое последнее сообщение там смотри. Как раз об этом и написано.