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

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

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

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


person Michael McGowan    schedule 05.10.2011    source источник
comment
Думаю, вам не стоит беспокоиться об этом ограничении в течение нескольких лет.   -  person Thomas Jungblut    schedule 05.10.2011
comment
Добавление дополнительной памяти на самом деле помогает сборщику мусора, потому что он вынужден запускаться реже.   -  person Blindy    schedule 05.10.2011
comment
В худшем случае Время полной сборки мусора обычно пропорционально размеру используемой кучи. Грубое приближение - 1 секунда на ГБ. Полный GC минут будет недоступен для большинства приложений.   -  person Peter Lawrey    schedule 05.10.2011
comment
С выходом v1.9 JVM более удобный для сервера сборщик мусора G1 теперь будет быть по умолчанию. Насколько я понимаю, это означает, что частичные чистки сборщика мусора будут происходить чаще, но гораздо короче.   -  person Dan Ross    schedule 01.04.2017


Ответы (6)


Если вы хотите использовать 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.

person Peter Lawrey    schedule 05.10.2011
comment
32-битные ссылки могут адресовать только до 4 ГБ, не так ли? Как бы вы настроили 64-битные ссылки? - person Nicola Musatti; 05.10.2011
comment
@Peter 32-битный размер оперативной памяти составляет 4 ГБ. Так что я думаю, что вы ошиблись в информации о размере кучи для этого случая. - person Naveen Babu; 05.10.2011
comment
В 64-битной JVM в последних версиях по умолчанию включен -XX:+UseCompressedOops. При этом используются 32-битные сжатые ссылки на объекты. Поскольку объекты выровнены по 8 байтов (а младшие 3 бита их адресов всегда равны 0), он может ссылаться на 2 ^ 32 * 8 байтов или 32 ГБ. - person Peter Lawrey; 05.10.2011
comment
@ Питер Я не согласен. Линия от IBM WebSphere Commerce работает в 32-битном режиме. Хотя максимальный теоретический предел кучи для 32-разрядной JVM составляет 4 ГБ из-за различных ограничений и зарезервированных областей памяти, на практике пределы намного ниже. Из ссылка ibm - person Naveen Babu; 05.10.2011
comment
Это для 32-битной JVM, как говорится. На 64-битной JVM ограничение для 32-битных ссылок составляет 32 ГБ. oracle.com/technetwork/java/javase/tech/ -XX:+UseCompressedOops Enables the use of compressed pointers (object references represented as 32 bit offsets instead of 64-bit pointers) for optimized 64-bit performance with Java heap sizes less than 32gb. - person Peter Lawrey; 05.10.2011
comment
Я не думаю, что UseCompressedOops говорит об использовании 8-битных указателей. Причина, по которой я узнал, что у IBM есть детали, заключалась в том, что я посетил семинар IBM, и они предоставили эти детали. У них также есть тот же параметр UseCompressedOops, и его использование, как объяснил докладчик IBM, было для использования 32-битных указателей в большинстве случаев, так что управление памятью использовало 32-битные и экономило пространство кучи вместо использования 64-битных указателей, когда это возможно. Я постараюсь найти для вас эту презентацию. - person Naveen Babu; 05.10.2011
comment
Эти ссылки от oracle точно показывают, что он делает с генерируемым машинным кодом, демонстрируя, что адрес сдвинут на 3 бита. wikis.sun.com/display/HotSpotInternals/CompressedOops - person Peter Lawrey; 05.10.2011
comment
Разве этот ответ не упускает сути вопроса? Он запрашивает максимально возможное для 64-битных, в то время как это в основном фокусируется на сжатых oops и 32-битных, ни один из которых не относится к максимуму. - person the8472; 20.08.2015
comment
Думаю, вам лучше упомянуть, что это предположение о 64-битной машине. - person Yang_2333; 02.01.2019
comment
@ the8472 Я бы перечитал второе предложение еще раз. 64-разрядная JVM ограничена ОС, в которой она работает, и этот предел может измениться со временем. - person Peter Lawrey; 03.01.2019

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

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

Под «может масштабироваться» они, по-видимому, означают «спускаются колодцы», а не «спускаются вообще».

person NPE    schedule 05.10.2011

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

person Andrew    schedule 05.10.2011

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

person Martin    schedule 12.10.2012
comment
Все значения принимаются молча. Вопрос в том, подчиняются ли они JVM. - person EntangledLoops; 16.03.2016

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

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

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

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

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

person the8472    schedule 20.08.2015

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

person Bronan U    schedule 15.10.2019