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

Question

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

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

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

Answer 1

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

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

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

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

Сжатые упы в JVM Hotspot

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

Answer 2

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

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

По "могут масштабировать" онипо-видимому, означает «работает на скважинах», а не «работает на всех».

Answer 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

Answer 4

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

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

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

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

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

Answer 5

Я пытался -Xmx32255M принимается vmargs для сжатых операций.