Есть ли эквивалент оптимизации Google Closure для javascript, для Java?

Question

Мы видим в следующей записи в блоге: http://blog.fogus.me/2011/07/21/compiling-clojure-to-javascript-pt1/ некоторые довольно невероятные преобразования синтаксиса, упрощения, сделанные для языка программирования javascript, сделанные компилятором Google Closure.

У меня вопрос: есть ли что-то, что обеспечивает такого рода синтаксические преобразования для Java?

Answer 1

Компилятор Closure работает так, как работает, потому что JavaScript, в отличие от Java, обычно распространяется в виде исходного кода. Такие действия, как переименование переменных и устранение пробелов, не применимы к Java, поскольку приложения Java обычно распространяются в виде байт-кода (часто упаковываются в файлы JAR).

Что касается остальной части оптимизации, то компилятор Java и JVM Hotspot включают в себя ряд методов, которые очень хороши для оптимизации вашего приложения и повышения производительности: многие из них просто происходят без вашего ведома.

Answer 2

Как правило, компилятор Java может / делает некоторые полезные оптимизации для создания кода JVM. Компилятор JIT в JVM затем выполняет больше оптимизаций, поскольку генерирует машинный код. Поскольку оба они являются автоматическими и невидимыми для вас, вы этого не замечаете, но вам не нужно делать это явно.

Всегда есть преобразования, которые могут быть выполнены в контексте вашей программы, которые Java-компилятор и JIT-компилятор не могут знать. Для этого в идеале вам нужна какая-то система преобразования исходного кода , которая может считывать исходный код, анализировать его в какой-то внутренней структуре инструмента (обычно AST), применять «невероятные синтаксические преобразования». ", который вы определяете для этой внутренней структуры, а затем восстанавливаете исходный код на своем языке.

Наш инструментарий реинжиниринга программного обеспечения DMS (коммерческий) является таким движком; он обрабатывает много языков. DMS имеет интерфейс Java 1.6 , который создает полные таблицы символов и обеспечивает анализ управления и потока данных, необходимые для более сложных преобразований.

Бесплатные альтернативы (университетские исследования): Stratego и TXL , оба из которых имеют анализаторы Java некоторой (неизвестной мне) зрелости, но определенно не предоставляют таблицы символов или какие-либо анализ потоков, то есть вы сами должны построить это или плохое приближение. Есть люди, которые могут предложить ANTLR , который также имеет внешний интерфейс Java, вероятно, создает AST, очень вероятно, не создает таблицы символов и не предоставляет остальную часть механизма, которую делают типичные системы преобразования ( преобразования источника в источник, восстановление исходного текста и т. д.)

Если вы довольны тем, что делает компилятор Java, вам это не нужно. Если этого недостаточно, то вы хотите что-то подобное. [Тот факт, что вы задали вопрос, наводит на мысль, что у вас есть представление о том, что вы хотите сделать, чего не делает компилятор Java. Хотите уточнить?]

Answer 3

У меня вопрос: есть ли что-то, что обеспечивает такого рода синтаксические преобразования для Java?

ИМО, не совсем.

• Компилятор Google Closure принимает Javascript в качестве входных данных и выполняет высокоуровневые преобразования (относительно семантически богатого) Javascript AST.

• Компиляторы байт-кода Java могли бы это сделать, но, видимо, мало что делают для оптимизации на уровне Java AST. Вместо этого они оставляют большую часть оптимизации компилятору JIT ... который оптимизирует, начиная с (относительно семантически плохого) файла класса; т.е. байт-коды.

Это затрудняет выполнение JIT-компилятором тех оптимизаций, которые может выполнять компилятор Google Closure.

Так почему же нет эквивалента Google Closure для Java? Есть две возможные причины:

• Потому что никто этого не сделал. (Я не могу вспомнить какие-либо конкретные примеры ...)

• Поскольку возможности для оптимизации отсутствуют, для обычного рукописного ввода Java.

• Технические причины (см. Ниже).

IMO это в основном вторая причина. Динамическая природа Javascript и типичных Javascript-программ означает, что существует больше возможностей для оптимизации с помощью преобразования AST, и что оптимизатор уровня AST обеспечит более значительное ускорение для нормального кода.

Теперь вполне может быть , если исходный код Java, созданный компилятором Clojure, предоставит больше возможностей для оптимизации на уровне AST. И это может быть хорошей идеей вернуться к предыдущим попыткам оптимизации уровня AST для Java (при условии, что они существовали).

«Технические причины», на которые я ссылался выше, включают следующее:

• Наличие определенных средств отражения и самоанализа в Java на самом деле является препятствием для оптимизации. Например, заявленная причина того, что компиляторы Java не могут выполнять оптимизацию хвостового вызова, заключается в том, что он нарушает код Java, который не полагается на невозможность просмотра стека вызовов. И одним из примеров является менеджер безопасности.

• Компиляторы байт-кода Java в основном работают на уровне отдельных модулей компиляции; то есть отдельные классы / интерфейсы / и т. д. Тип высокоуровневых оптимизаций, выполняемых компилятором Google Closure, включает входные файлы, содержащие много классов.