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

[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 совместимость с этими эльфами.