Почему максимальный размер кучи Java фиксирован?

Ответ 1

В Sun JVM, я знал, что вся куча должна быть выделена в смежном адресном пространстве. Я полагаю, что для больших значений кучи, довольно сложно добавить в ваше адресное пространство после запуска, при этом он остается смежным. Вы, вероятно, должны получить его при запуске, или совсем нет. Таким образом, он фиксирован.

Даже если он не используется сразу, адресное пространство для всей кучи зарезервировано при запуске. Если он не может зарезервировать достаточно большой непрерывный блок адресного пространства для значения -Xmx, которое вы передадите, он не запустится. Вот почему сложно выделить > 1,4 ГБ кучи на 32-битной Windows - потому что трудно найти смежное адресное пространство в этом размере или больше, так как некоторые DLL любят загружать в определенных местах, фрагментируя адресное пространство. Это не проблема, когда вы переходите на 64-разрядную версию, так как там гораздо больше адресного пространства.

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

Причина, по которой нам нужна непрерывная память регион для кучи состоит в том, что мы имеем связка боковых структур данных, которые индексируются (масштабированными) смещениями из начало кучи. Например, мы отслеживать ссылки на объект "массив маркеров карт", который имеет один байт для каждых 512 байтов кучи. Когда мы храните ссылку в куче, которую мы имеем отметить соответствующий байт в массив маркеров. Мы правильно сдвигаем адрес назначения магазина и используйте, чтобы индексировать массив маркеров. Веселые арифметические игры не может сделать на Java, к которому вы to:-) играть на С++.

Это было в 2004 году - я не уверен, что изменилось с тех пор, но я уверен, что он все еще держится. Если вы используете такой инструмент, как Process Explorer, вы можете видеть, что виртуальный размер (добавить столбцы памяти виртуального размера и частного размера) приложения Java включает в себя полный размер кучи (плюс другое необходимое пространство, без сомнения), начиная с момента запуска, хотя память, используемая этим процессом, не будет там, где до тех пор, пока куча не начнет заполняться...

Ответ 2

Исторически сложилось так, что это ограничение было причиной, которая не позволяла апплетам в браузере потреблять всю память пользователей. Виртуальная машина Microsoft, которая никогда не имела такого ограничения, фактически позволяла это делать, что могло привести к какой-то атаке "Отказ в обслуживании" против компьютера пользователя. Только год назад Sun представила версию 1.6.0 Update 10 VM, чтобы позволить апплетам указать, сколько памяти они хотят (ограничено определенной фиксированной долей физической памяти), а не всегда ограничивать их до 64 МБ даже на компьютерах которые имеют 8 ГБ или более.

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

Ответ 3

Я думаю, что короткий, пристойный ответ - это потому, что Солнце не нашло того, что стоит времени и затрат на разработку.

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

Ответ 4

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

Если вы задаете максимальный размер кучи, например, объем ОЗУ на коробке, вы фактически позволяете ВМ решить, сколько памяти он требует (до этого предела). Проблема заключается в том, что виртуальная машина может эффективно калечить машину, на которой она запущена, потому что она возьмет на себя всю память на коробке, прежде чем она решит, что ей нужно собрать мусор.

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

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

Ответ 5

Из IBM советы по настройке производительности (поэтому это может быть не применимо непосредственно к виртуальным машинам Sun)

Параметры кучи Java влияют на поведение сбора мусора. Увеличение размера кучи поддерживает большее количество объектов. Поскольку большая куча занимает больше времени для заполнения, приложение работает дольше, чем происходит сбор мусора. Тем не менее, большая куча также занимает больше времени, чтобы сжимать и заставлять сбор мусора занимать больше времени.

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

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

В общем случае VM не будет использовать максимальный размер кучи, если это вам не понадобится, поэтому, если вы считаете, что вам нужно будет расширить память во время выполнения, вы можете просто указать большой размер максимальной кучи.

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