Каков максимальный размер кучи с 64-битной JVM?

Теоретическое значение максимальной кучи, которое может быть установлено с помощью -Xmx в 32-битной системе, конечно, 2^32 байтов, но обычно (см. Понимание максимального размера кучи JVM - 32bit против 64bit) нельзя использовать все 4GB.

Для 64-разрядной JVM, работающей в 64-разрядной ОС на 64-разрядной машине, существует ли какой-либо предел, кроме теоретического предела 2^64 байтов или 16 экзабайтов?

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

Ответ 1

Если вы хотите использовать 32-битные ссылки, ваша куча ограничена 32 ГБ.

Однако, если вы хотите использовать 64-битные ссылки, размер, скорее всего, будет ограничен вашей ОС, как и с 32-разрядной JVM. например на 32-разрядной версии Windows это от 1,2 до 1,5 ГБ.

Примечание: вы захотите, чтобы ваша куча JVM вписывалась в основную память, идеально внутри одной области NUMA. Это около 1 ТБ на больших машинах. Если ваша JVM охватывает области NUMA, доступ к памяти и GC, в частности, займет намного больше времени. Если ваша куча JVM начнет меняться, это может занять часы до GC или даже сделать ваш компьютер непригодным, поскольку он разбивает накопитель подкачки.

Примечание. Вы можете получить доступ к большим размерам с прямой памятью и памятью, даже если вы используете 32-битные ссылки в своей куче. то есть использовать значительно выше 32 ГБ.

Сжатый сбой в JVM Hotspot

Сжатые oops представляют управляемые указатели (во многих, но не во всех местах JVM), как 32-битные значения, которые необходимо масштабировать в 8 раз и добавлять к 64-разрядному базовому адресу, чтобы найти объект, на который они ссылаются. Это позволяет приложениям адресовать до четырех миллиардов объектов (не байтов) или размер кучи до 32 Гб. В то же время компактность структуры данных конкурирует с режимом ILP32.

Ответ 2

Ответ явно зависит от реализации JVM. Azul утверждают, что их JVM

может масштабироваться... до более чем 1/2 терабайта памяти

Под "можно масштабировать" они означают "работает колодцы", в отличие от "работает на всех".

Ответ 3

Windows накладывает ограничение на память для каждого процесса, вы можете видеть, что это для каждой версии здесь

Смотрите:

User-mode virtual address space for each 64-bit process; With IMAGE_FILE_LARGE_ADDRESS_AWARE set (default): x64: 8 TB Intel IPF: 7 TB 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared

Ответ 4

Я пробовал -Xmx32255M принимал vmargs для сжатых oops.

Ответ 5

Для 64-разрядной JVM, работающей в 64-разрядной ОС на 64-битной машине, существует ли какой-либо предел, кроме теоретического предела в 2 ^ 64 байта или 16 экзабайтов?

Вам также необходимо учитывать лимиты оборудования. Хотя указатели могут быть 64-битными текущими процессорами, можно адресовать менее 2 ^ 64 байтов виртуальной памяти.

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

И третий - практичность. Даже если вы можете иметь такую большую виртуальную память, это не означает, что ЦП поддерживают такую физическую память, и без физической памяти вы в конечном итоге свопите, что отрицательно скажется на производительности JVM, потому что GC, как правило, должны касаться большой доли кучи.

В качестве других ответов упоминается сжатие oops: путем наложения выравнивания объекта выше 8 байтов пределы со сжатыми oops могут быть увеличены за пределами 32 ГБ

Ответ 6

В теории все возможно, но в реальности вы обнаружите, что цифры намного ниже, чем вы могли ожидать. Я пытался часто обращаться к огромным пространствам на серверах и обнаружил, что, хотя сервер может иметь огромные объемы памяти, он удивил меня, что большинство программ фактически никогда не могут решить эту проблему в реальном сценарии просто потому, что процессор не достаточно быстр, чтобы реально решать их , Почему вы говорите правильно?!, Время - это бесконечное падение каждой огромной машины, над которой я работал. Поэтому я бы посоветовал не идти за борт, обращаясь к огромным суммам только потому, что вы можете, но используйте то, что, по вашему мнению, можно использовать. Фактические значения часто намного ниже, чем вы ожидали. Конечно, никто из нас действительно не использует системы HP 9000 дома, и большинство из вас когда-либо будет приближаться к емкости вашей домашней системы. Например, большинство пользователей не имеют более 16 ГБ памяти в своей системе. Конечно, некоторые случайные геймеры используют рабочие станции для игры один раз в месяц, но я держу пари, что это очень маленький процент. Таким образом, спуск на землю означает, что я бы обратился в 64-битной системе на 8 ГБ не намного больше, чем 512 МБ для пространства кучи или, если вы перешли за борт, попробуйте 1 ГБ. Я почти уверен, что даже с этими цифрами просто перебор. Я постоянно следил за использованием памяти во время игр, чтобы увидеть, будет ли адресация иметь какое-либо значение, но не заметил никакой разницы, когда я обращался к гораздо более низким или большим значениям. Даже на сервере/рабочих станциях не было видимых изменений в производительности, независимо от того, насколько велики я установил значения. Это не означает, что некоторые пользователи jave могли бы использовать больше адресованного пространства, но пока я не видел ни одного из приложений, нуждающихся в таком большом количестве когда-либо. Конечно, я предполагаю, что их производительность будет незначительной, если у экземпляров java не хватит места для работы. На данный момент я ничего такого не обнаружил, однако нехватка реальной установленной памяти показала мгновенное падение производительности, если вы установили слишком много пространства кучи. Когда у вас есть система 4 Гб, вы быстро запускаете из пространства кучи, а затем вы видите некоторые ошибки и замедления, потому что люди обращаются к слишком большому пространству, которое на самом деле не свободно в системе, поэтому ОС начинает обращаться к дисковому пространству, чтобы восполнить недостаток следовательно, он начинает меняться.

Ответ 7

Существует множество переменных при определении максимального размера кучи. И в верхней части головы я могу думать:

ОС, которые вы используете
Размер корпуса вашего аппарата.
выполняемые приложения, для вычисления других приложений Использование ОЗУ

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

Тем не менее, если вам нужно найти максимальный размер, вот факты, которые я слышал или читал о

Значения требований к размеру оперативной памяти OS

XP использует 1 ГБ оперативной памяти
Vista/Seven использует не менее 2-3 ГБ для бесперебойной работы
Я думаю, что размер RAM для Linux равен arround 1-2 GB

Теперь мы можем надеяться, что ваша JAVA VM не будет работать полностью. Поэтому мы можем игнорировать другое программное обеспечение, работающее в вашей системе. Таким образом, ваш размер (Physical RAM size - OS RAM size requirement) предоставит вам максимальный размер кучи .

Итак, для машины с 8Gb, работающей на win7, вы можете иметь размер кучи (8Gb - 3bb) = 5Gb.

отредактирован: ссылка ibm для максимального размера кучи