19.3.2010, 13:45
Для чего перекомпилировать 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
Как работают большинство виртуальных машин на стадии выполнения кода: загружают код методов класса, и затем из него создают новый код, машинный(нативный). Это называется 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
