статический оптимизатор байт-кода Java (например, Proguard) с анализом escape? - PullRequest
7 голосов
/ 11 июня 2010

Оптимизация на основе анализа побега является запланированной функцией Proguard.В то же время, существуют ли какие-либо инструменты, такие как proguard, которые уже выполняют оптимизацию, требующую анализа побега?

Ответы [ 2 ]

3 голосов
/ 14 июня 2010

Да, я думаю, Каркасная сажа выполняет анализ побега.

1 голос
/ 20 июня 2010

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

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

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

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

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

...