Я только что попробовал -XX:+DoEscapeAnalysis
опция включила на jdk6-u18 VM (на solaris) и имела довольно неутешительный опыт. Я запускаю scala приложение, которое имеет слишком много агентов (20,000 из них). Это - рецепт для создания мусора!
Обычно приложение может работать с 256 МБ "кучи", но генерирует огромные количества мусора. В его устойчивом состоянии это:
Я думал, что escape-анализ мог бы помочь так, я включил опцию и повторно выполнил приложение. Я нашел, что приложение стало все больше не могущим убрать мусор, который оно собрало, пока это, казалось, в конечном счете не провело все время, делая GC, и приложение "застопорилось" при его полном выделении.
В этой точке я должен сказать, что приложение не бросило a OutOfMemoryError
который я ожидал бы. Возможно, JConsole
(который я использовал для выполнения, анализ) правильно не отображает статистику GC с этой опцией на (я не убежден)?
Я затем удалил опцию и перезапустил, и приложение стало "нормальным" снова! У кого-либо есть какая-либо идея, что могло бы продолжаться?
1 Показался ли в JConsole активированный анализ перехода? Убедитесь, что вы запускаете виртуальную машину с параметром -server. Я предполагаю, что у вас это сработало, но я просто подумал, что проверю.
2 Я не думаю, что анализ побега поможет ситуации с Scala Actors. Вы можете увидеть большой выигрыш, если сделаете что-то вроде:
def act():Unit = {
val omgHugeObject = new OMGHugeObject();
omgHugeObject.doSomethingCrazy();
}
В приведенном выше примере EscapeAnalysis сделает так, чтобы omgHugeObject
можно было разместить в стеке, а не в куче, и таким образом не создать мусор. Я не думаю, что анализ побега поможет с актерами. Их ссылки всегда будут «уходить» в подсистему акторов.
3 Вы используете самую последнюю версию Scala? Произошла утечка памяти, которая, как мне кажется, была исправлена в последней версии. Это даже привело к тому, что Lift породил свою собственную библиотеку Actor, в которую вы могли бы заглянуть.
4 Вы можете попробовать сборщик G1Garbage. Вы можете включить его с помощью:
-XX: + UnlockExperimentalVMOptions -XX: + UseG1GC
Обратите внимание, что оптимизация на основе Escape-анализа (-XX:+DoEscapeAnalysis) отключена в 6u18. Эта опция будет восстановлена в будущем обновлении Java SE 6.
Я предлагаю вам попробовать увеличить размер нового поколения, например -XX: NewSize = 96M XX: NewRatio = 3
. Используйте JVisualVM (входит в состав JDK) с подключаемым модулем Visual GC , чтобы посмотреть, как используются молодые и старые пространства.