7

jdk6-u18 VM (solaris 上) で-XX:+DoEscapeAnalysisオプションを有効にしてみましたが、かなり残念な結果でした。私はかなり多くのアクター (20,000 人) を持つ scala アプリケーションを実行しています。ガベージ作成のレシピです！

通常、アプリは 256Mb のヒープで実行できますが、大量のガベージが生成されます。定常状態では:

  • GC に 10% の時間を費やす
  • 30 秒未満で 150Mb を超えるガベージが生成され、その後 GC が実行されます

エスケープ分析が役立つかもしれないと思ったので、オプションを有効にしてアプリを再実行しました。アプリが収集したガベージをますます消去できなくなり、最終的に GC の実行にすべての時間を費やすようになり、アプリが完全な割り当てで「フラットライン」になることがわかりました。

OutOfMemoryErrorこの時点で、アプリは期待していた をスローしなかったと言わざるを得ません。おそらくJConsole（分析を実行するために使用していた）このオプションをオンにすると、GC統計が正しく表示されないのでしょうか（確信が持てません）？

その後、オプションを削除して再起動すると、アプリは再び「通常」になりました! 何が起こっているのか誰にも分かりますか？

4

3 に答える 3

8

1 JConsole でエスケープ分析が有効になっていると表示されましたか? -server オプションを使用して VM を実行していることを確認する必要があります。これは機能していると思いますが、確認してみようと思いました。

2エスケープ分析が Scala アクターの状況に役立つとは思いません。次のようなことをすると、大きな利益が得られる可能性があります。

def act():Unit = {
   val omgHugeObject = new OMGHugeObject();
   omgHugeObject.doSomethingCrazy();
 }

上記の例では、EscapeAnalysis によってomgHugeObjectヒープではなくスタックに割り当てられるため、ガベージが作成されません。逃亡分析が俳優に役立つ可能性は低いと思います。それらの参照は常にアクター サブシステムに「エスケープ」されます。

3 Scala の最新リリースを使用していますか? 最近のバージョンで修正されたと思われるメモリ リークがありました。これにより、Liftが独自の Actor ライブラリからスポーンすることさえありました。

4 G1Garbage コレクターを試すことができます。次の方法で有効にできます。

-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC

于 2010-02-01T20:47:33.350 に答える
6

jdk-u18 リリース ノートから:

エスケープ解析ベースの最適化 (-XX:+DoEscapeAnalysis) は 6u18 では無効になっていることに注意してください。このオプションは、将来の Java SE 6 アップデートで復元される予定です。

于 2010-02-02T12:31:05.243 に答える
3

新しい世代のサイズを大きくすることをお勧めします-XX:NewSize=96M XX:NewRatio=3。JVisualVM (JDK に含まれています) とVisual GCプラグインを使用して、若いスペースと古いスペースがどのように利用されているかを監視します。

于 2010-02-01T20:57:34.290 に答える