Почему размер кучи фиксирован на JVM?

Может кто-нибудь объяснить мне, почему JVM (я не проверял слишком много, но я никогда не видел такой, которая не делала так) должны работать с фиксированным размером кучи? Я знаю, что проще реализовать в простой непрерывной куче, но JVM Sun уже более десяти лет, поэтому я ожидаю, что у них было время, чтобы улучшить это.

Необходимость определить максимальный объем памяти вашей программы во время запуска кажется делом 1960-х годов, а затем возникают плохие взаимодействия с управлением виртуальной памятью ОС (сбор данных извлекается из памяти, невозможность определить, сколько памяти занимает процесс Java). действительно используя со стороны ОС, огромное количество пространства ВМ тратится впустую (я знаю, вам все равно на ваших модных 48-битных машинах ...)). Я также предполагаю, что различные печальные попытки создания небольших операционных систем внутри JVM (серверы приложений EE, OSGi), по крайней мере, частично виноваты в этом обстоятельстве, потому что запуск нескольких процессов Java в системе неизменно приводит к потере ресурсов, потому что вы должны дать каждому из них память, которую он может использовать в пике.

Удивительно, но Google не вызвал бурь возмущения по поводу этого, что я ожидаю, но они могли быть просто похоронены под миллионами людей, узнавших о фиксированном размере кучи и просто приняв это за факт.

Вы неправы. Размер кучи JVM не фиксирован, а ограничен:

• -Xmx устанавливает максимальный объем памяти кучи
• -Xms устанавливает минимальный объем памяти кучи

Установка верхнего предела необходима по нескольким причинам. Во-первых, он сообщает сборщику мусора, когда начинать действовать. Во-вторых, это предотвращает засорение JVM всей машины, потребляя слишком много памяти. Минимальный размер кучи, вероятно, полезен для резервирования того объема памяти, который необходим программе, по крайней мере, для предотвращения нехватки памяти (поскольку другие процессы потребляют слишком много).

Я полагаю, что ответ имеет отношение к наследию Java. Первоначально он был разработан как язык, который будет использоваться для встроенных систем, где очевидно, что ресурсы ограничены, и вы не хотите, чтобы процессы просто сожрали все, что доступно. Это также помогает в системном администрировании, поскольку упрощает выделение ресурсов на сервере, если вы можете установить ограничения ресурсов. Я вижу, что последние версии JVM, похоже, используют несколько не непрерывных куч, хотя, конечно, все это выглядит как одна куча для вашего кода.

(FWIW, вы должны были указать требования к памяти для программы в версиях Apple, предшествовавших Darwin MacOS [во всяком случае, вплоть до System 7, которая была последней, которую я использовал), что было в 80-е годы.)

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

Ключ должен установить правильные границы. Я смотрю -msкак «это то, сколько памяти требуется моему приложению» и -mxкак «оно никогда не должно превышать это количество». В производственном развертывании оба должны быть близкими, если не равными, и они должны основываться на фактических, измеренных требованиях.

Ваши опасения по поводу «потраченной впустую» виртуальной памяти неуместны: она виртуальная, она (почти) бесплатная. Да, выделение кучи слишком большого размера означает, что вы не можете запустить столько потоков или загрузить столько файлов с отображенной памятью. Но это часть дизайна приложения: у вас ограниченные ресурсы, вам нужно разделить их так, чтобы ваше приложение могло работать. В куче "C-style", которая будет расширяться до тех пор, пока вы не достигнете вершины памяти, основная проблема остается той же, вам просто не нужно думать об этом, пока у вас не возникнут проблемы.

Единственное, что большая куча может «расточить» - это пространство подкачки, потому что все записываемые сегменты требуют обязательной подкачки. Но это является частью конструкции системы: если вы хотите, чтобы на одной машине было запущено много JVM, увеличьте объем подкачки или уменьшите выделение кучи. Если они начинают биться, вы пытаетесь сделать слишком много с системой; купите больше памяти (и если вы все еще используете 32-битный процессор, купите новую коробку).

Как говорит user281377, вы указываете только верхний предел того, сколько памяти может занимать ваш процесс . Конечно, само приложение будет занимать только необходимое ему пространство.

Должен ли существовать верхний предел по умолчанию или нет - это другой вопрос, как за, так и против.