Почему у Java такой большой след? - PullRequest
15 голосов
/ 10 июля 2009

Java - или, по крайней мере, Sun Hotspot JVM - давно имеет репутацию очень большого объема памяти. Что именно в JVM дает ему такую ​​репутацию? Я был бы заинтересован в подробном разборе: сколько памяти уходит во время выполнения (JIT? GC / управление памятью? Загрузчик классов?), Что-нибудь связанное со "вспомогательными" API, такими как JNI / JVMTI? стандартные библиотеки? (какие части получают сколько?) любые другие основные компоненты?

Я понимаю, что на этот вопрос может быть непросто ответить без конкретного приложения и конфигурации виртуальной машины, поэтому просто сужу хотя бы несколько вещей: меня в первую очередь интересуют стандартные / типовые конфигурации виртуальной машины и базовая консоль "Hello" world ", а также любое реальное приложение для настольного компьютера или сервера. (Я подозреваю, что значительная часть занимаемой площади JVM в значительной степени не зависит от самого приложения, и именно в этой части я хотел бы увеличить изображение в идеале.)

У меня есть пара других тесно связанных вопросов:

  • Другие аналогичные технологии, такие как .NET / mono, не демонстрируют практически такой же отпечаток. Почему это так?

  • Я читал где-то на интранетах, что большая часть занимаемой площади связана просто с размером стандартных библиотек. Если это так, то почему так много стандартных библиотек загружается заранее?

  • Предпринимаются ли какие-либо усилия (JSR, что угодно) для укрощения памяти? Самым близким, с чем я столкнулся, является проект по уменьшению занимаемой диском площади JVM .

  • Я уверен, что площадь следа менялась за последнее десятилетие или около того с каждой новой версией Java. Существуют ли какие-либо конкретные цифры / графики, точно описывающие, как сильно изменилась площадь JVM?

Ответы [ 3 ]

7 голосов
/ 10 июля 2009

Некоторые инициативы:

5 голосов
/ 10 июля 2009

У нас есть некоторые серверные приложения, которые не выполняют ничего, кроме моста многоадресного трафика (т. Е. У них нет постоянного состояния). Все они работают с 2,3 - 2,5 МБ кучи на 32-битной Java6 (linux) JRE.

Это большой след? Я мог бы легко получить тысячу из них на типичной машине серверного класса (с точки зрения memory ), хотя это было бы бессмысленно с точки зрения threading !

Тем не менее, существует проект Jigsaw для модульной виртуальной машины (библиотеки, в которые я верю), которая появится в Java7; это поможет тем, кто желает иметь меньшие следы.

Я понимаю, что это на самом деле не отвечает на ваш вопрос, но, тем не менее, это актуально! Какие приложения вы разрабатываете, когда обнаруживаете, что объем памяти является проблемой?

0 голосов
/ 10 июля 2009

По крайней мере, одна вещь - это длинная история Java - она ​​началась в 1995 году и теперь является версией 6. Сохранение обратной совместимости при одновременном добавлении функций неизбежно увеличивает ее площадь. Это изображение говорит о многом ...

...