Перекомпиляция 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- а перекомпиляция.