Почему управление памятью так заметно в Java VM?

Question

Я работаю над тем, чтобы написать несколько простых веб-приложений на основе Spring и развернуть их в Tomcat. Почти сразу же я столкнулся с необходимостью настроить параметры JVM Tomcat с помощью -XX: MaxPermSize (и -Xmx и -Xms); без этого серверу легко не хватает места PermGen.

Почему эта проблема возникает для виртуальных машин Java по сравнению с другими языками сборки мусора? Сравнение показателей «настройки памяти X» для X в Java, Ruby, Perl и Python показывает, что у Java легко на порядок больше посещений в Google, чем в других языках вместе взятых.

Мне также могут быть интересны ссылки на технические документы / публикации в блогах / и т. Д., В которых объясняется выбор дизайна за реализацией GC JVM, для разных JVM или для сравнения с виртуальными машинами с другими интерпретированными языками (например, сравнение Sun или IBM JVM с Parrot ). Существуют ли технические причины, по которым пользователям JVM все еще приходится иметь дело с размерами кучи / permgen без автоматической настройки?

Answer 1

Название вашего вопроса вводит в заблуждение (не нарочно, я знаю): проблемы PermSize (и их много, я был одним из первых, кто диагностировал проблему Tomcat / Sun PermGen много лет назад, когда еще не было никаких знаний по этому вопросу) не специфика Java, а спецификация Sun VM.

Если вы используете виртуальную машину, которая не использует постоянную генерацию (как, скажем, IBM VM, если я не ошибаюсь), у вас не будет проблем с permgen.

Так что это не проблема "Java", а проблема реализации Sun VM.

Answer 2

Java дает вам немного больше контроля над памятью - поразите тех, кто хочет применить , которые контролируют там, по сравнению с Ruby, Perl и Python, которые дают вам меньше контроля над этим. Типичная реализация Java также очень требовательна к памяти (потому что она имеет более продвинутый подход к сбору мусора) по сравнению с типичными реализациями динамических языков ... но если вы посмотрите на JRuby или Jython, вы обнаружите, что не проблема языка (когда эти разные языки используют одну и ту же базовую виртуальную машину, проблемы с памятью в значительной степени компенсируются). Я не знаю о широко распространенной реализации "Perl на JVM", но, если есть такая, которую я готов поспорить, она не будет заметно отличаться с точки зрения следа от JRuby или Jython!

Answer 3

Python / Perl / Ruby выделяет свою память с помощью malloc () или ее оптимизации. Ограничение пространства кучи определяется операционной системой, а не виртуальной машиной, поэтому нет необходимости использовать такие параметры, как -Xmxn. Кроме того, сборка мусора проще, основанная главным образом на подсчете ссылок. Так что для настройки гораздо меньше.

Кроме того, динамические языки, как правило, реализуются с помощью интерпретаторов байт-кода, а не JIT-компиляторов, поэтому они все равно не используются для кода, критичного к производительности.

Answer 4

Суть ответов @WizardOfOdds и @ Alex-Martelli представляется правильной: Java имеет расширенный набор опций GC, и иногда вам необходимо настроить их. Однако я до сих пор не совсем понимаю, почему вы можете создать JVM с постоянным поколением или без него. Я нашел кучу полезных ссылок о сборке мусора в Java, хотя и не обязательно по сравнению с другими языками с GC. Кратко:

• Sun GC развивается очень медленно из-за того, что он развернут повсюду, и люди могут рассчитывать на причуды в его реализации.
• У Sun есть подробные технические документы о дизайне и параметрах GC, такие как Настройка сборки мусора с виртуальной машиной Java [tm] 5.0 * .
• В крыльях новый GC, называемый G1 GC. У Алекса Миллера есть хорошее резюме соответствующих сообщений в блоге и ссылка на технический документ. Но у него все еще есть постоянное поколение (и не обязательно делает большую работу с ним ).
• Джон Масамицу имеет (имел?) Интересный блог в Sun, посвященный различным деталям сбора мусора.

Рад обновить этот ответ с более подробной информацией, если у кого-то есть.

Answer 5

Это потому, что Tomcat работает на виртуальной машине Java, в то время как другие языки либо компилируются, либо интерпретируются и работают на вашей реальной машине. Когда вы устанавливаете -Xmx и -Xms, вы говорите, что хотите, чтобы JVM работала как компьютер с количеством оперативной памяти где-то в заданном диапазоне.

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