статический оптимизатор байт-кода Java (как прозащита) с escape-анализом?

Чего вы ожидаете от escape-анализа на уровне компилятора? Классы Java больше похожи на объектные файлы в C - они связаны в JVM, поэтому анализ выхода может выполняться только на уровне одного метода, который имеет ограниченное удобство использования и будет затруднять отладку (например, у вас будут строки кода через на которую нельзя ступить).

В дизайне Java компилятор довольно тупой - он проверяет правильность (как Lint), но не пытается оптимизировать. Умные части помещаются в JVM - она ​​использует несколько методов оптимизации, чтобы получить хорошо работающий код на текущей платформе в текущих условиях. Поскольку JVM знает весь код, который в настоящее время загружен, она может предполагать гораздо больше, чем компилятор, и выполнять спекулятивные оптимизации, которые отменяются в тот момент, когда предположения становятся недействительными. HotSpot JVM может заменять код более оптимизированной версией «на лету», пока функция работает (например, в середине цикла, когда код становится «горячее»).

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

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

В целом, чем больше информации JVM имеет о вашем исходном коде, тем лучше она может его оптимизировать. И оптимизации, которые выполняет JVM, постоянно улучшаются, поэтому я бы подумал об оптимизации скомпилированного кода только тогда, когда говорю об очень ограниченных и базовых JVM, таких как мобильные телефоны. В этих случаях вы все равно хотите запустить приложение через обфускатор (для сокращения имен классов и т. Д.)