Почему у Java такой большой след?

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

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

У меня есть еще несколько близких вопросов:

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

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

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

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

Ответы

Ответ 1

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

Ответ 2

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

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

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

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

Ответ 3

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