7

我刚刚尝试了在jdk6-u18-XX:+DoEscapeAnalysis VM（在 solaris 上）上启用的选项，但体验相当令人失望。我正在运行一个 scala 应用程序，它有很多演员（其中 20,000 个）。这是制造垃圾的秘诀！

通常，应用程序可以在 256Mb 的堆上运行，但会产生大量垃圾。在其稳定状态下：

  • 在 GC 上花费 10% 的时间
  • 在 <30 秒内生成 >150Mb 的垃圾，然后被 GC 处理

我认为逃逸分析可能会有所帮助，因此我启用了该选项并重新运行了该应用程序。我发现该应用程序越来越无法清除它收集的垃圾，直到它似乎最终将整个时间都花在了GC 上，并且该应用程序在其全部分配时“扁平化”了。

在这一点上，我应该说该应用程序没有抛出OutOfMemoryError我所期望的。也许JConsole（我用来执行分析）没有正确显示带有此选项的 GC 统计信息（我不相信）？

然后我删除了该选项并重新启动，应用程序再次变得“正常”！有人知道会发生什么吗？

4

3 回答 3

8

1逃逸分析是否显示为在 JConsole 中启用？您需要确保使用 -server 选项运行 VM。我假设你有这个工作，但我只是想我会检查一下。

2我认为逃逸分析不会对 Scala Actors 的情况有所帮助。如果您执行以下操作，您可能会看到很大的收获：

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

在上面的示例中，EscapeAnalysis 将使其omgHugeObject可以分配在堆栈而不是堆上，因此不会产生垃圾。我认为逃逸分析不太可能对演员有所帮助。他们的引用总是“逃逸”到actor子系统。

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 回答