Статический оптимизатор байт-кода Java (например, Proguard) с анализом escape?
Оптимизация на основе анализа побега является запланированной функцией Proguard. Между тем, существуют ли какие-либо инструменты, такие как proguard, которые уже выполняют оптимизацию, требующую анализа побега?
2 ответа
Что вы ожидаете от escape-анализа на уровне компилятора? Java-классы больше похожи на объектные файлы в C - они связаны в JVM, поэтому анализ escape может быть выполнен только на уровне одного метода, который имеет ограниченную применимость и затруднит отладку (например, у вас будут строки кода через который вы не можете шагнуть).
В дизайне Java компилятор довольно тупой - он проверяет правильность (как Lint), но не пытается оптимизировать. Умные части помещены в JVM - он использует несколько методов оптимизации для получения хорошо работающего кода на текущей платформе в текущих условиях. Поскольку JVM знает весь код, который загружен в данный момент, он может предполагать намного больше, чем компилятор, и выполнять спекулятивную оптимизацию, которая отменяется в тот момент, когда предположения становятся недействительными. HotSpot JVM может заменить код более оптимизированной версией на лету во время работы функции (например, в середине цикла, когда код становится "горячим").
Когда не в отладчике, переменные с неперекрывающимися временами жизни свернуты, инварианты выведены из циклов, циклы развернуты и т. Д. Все это происходит в коде с JIT-кодом и выполняется в зависимости от того, сколько времени потрачено на эту функцию (нет смысла тратить время на оптимизацию кода, который никогда не запускается). Если мы выполним некоторые из этих оптимизаций заранее, у JIT будет меньше свободы, и общий результат может быть чистым отрицательным.
Другая оптимизация - это размещение в стеке объектов, которые не выходят за пределы текущего метода - это делается в некоторых случаях, хотя я где-то читал статью о том, что время для тщательного анализа escape-данных по сравнению с временем, полученным оптимизацией, говорит о том, что оно того не стоит, поэтому текущая стратегия более эвристична.
В целом, чем больше у JVM информации о вашем исходном коде, тем лучше он может оптимизировать его. И оптимизация, которую выполняет JVM, постоянно улучшается, поэтому я бы подумал об оптимизации скомпилированного кода, только когда говорил об очень ограниченных и базовых JVM, таких как мобильные телефоны. В этих случаях вы все равно хотите запускать ваше приложение через обфускатор (для сокращения имен классов и т. Д.)