エスケープ分析に基づく最適化は、Proguard で計画されている機能です。それまでの間、エスケープ解析を必要とする最適化を既に行っている、proguard のような既存のツールはありますか?
2 に答える
はい、Soot フレームワークはエスケープ分析を実行すると思います。
コンパイラ レベルでのエスケープ解析に何を期待しますか? Java クラスは C のオブジェクト ファイルに似ています。JVM でリンクされているため、エスケープ解析は単一メソッド レベルでのみ実行できます。これは使いやすさが制限され、デバッグが妨げられます (たとえば、あなたがステップすることはできません)。
Java の設計では、コンパイラはかなり馬鹿げています。(Lint のように) 正確性をチェックしますが、最適化を試みません。スマート ピースは JVM に配置されます。JVM は複数の最適化手法を使用して、現在の条件の下で現在のプラットフォームで適切に実行されるコードを生成します。JVM は現在ロードされているすべてのコードを認識しているため、コンパイラよりもはるかに多くのことを想定し、仮定が無効になった瞬間に元に戻される投機的な最適化を実行できます。HotSpot JVM は、関数の実行中にコードをより最適化されたバージョンにオンザフライで置き換えることができます (たとえば、コードが「ホット」になるループの途中で)。
デバッガーにない場合、重複しない有効期間を持つ変数は折りたたまれ、不変条件はループから引き上げられ、ループはアンロールされます。これはすべて JIT 化されたコードで発生し、この関数で費やされた時間に応じて行われます (決して実行されないコードの最適化に時間を費やすのはあまり意味がありません)。これらの最適化の一部を事前に実行すると、JIT の自由度が低下し、全体的な結果がマイナスになる可能性があります。
別の最適化は、現在のメソッドをエスケープしないオブジェクトのスタック割り当てです-これは特定のケースで行われますが、厳密なエスケープ分析を実行する時間と最適化によって得られる時間は、それが価値がないことを示唆しているという論文をどこかで読みました。現在の戦略はよりヒューリスティックです。
全体として、JVM が元のコードについて持っている情報が多いほど、より適切に最適化できます。また、JVM が行う最適化は常に改善されているため、携帯電話のような非常に制限された基本的な JVM について話す場合にのみ、コンパイル済みコードの最適化について考えます。このような場合、難読化ツールを使用してアプリケーションを実行する必要があります (クラス名を短縮するためなど)。