Почему установка слишком высокого значения -Xmx иногда приводит к сбою JVM, даже если имеется доступная оперативная память?

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

Так, например, на машине с 4 ГБ у нас есть -Xmx1024m, который дает сбой, но -Xmx800m работает. Я мог понять на машине с 1 ГБ, даже на машине с 2 ГБ, но на машине с 4 ГБ, особенно с учетом того, что Windows, Linux и т. Д. Могут выгружать ОЗУ, почему это не работает?

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

Кроме того, как вы говорите, потребляйте столько памяти, сколько хотите, до определенного размера?


person Stephane Grenier    schedule 05.01.2012    source источник
comment
Быстрый поиск приводит пользователей, которые удивлены тем, что JVM позволяет им устанавливать -Xmx в терабайты, даже если у них не так много места подкачки. Не могли бы вы поделиться точными командами и версиями JVM, которые вы тестировали?   -  person alf    schedule 06.01.2012
comment
@alf, имейте в виду, что -Xmx устанавливает максимальный размер кучи, который представляет собой просто размер зарезервированного диапазона виртуального адресного пространства; только объем, указанный в -Xms, фактически поддерживается выделенным хранилищем. Например, см. VirtualAlloc< /a> и сравните флаги MEM_RESERVE и MEM_COMMIT.   -  person Jeffrey Hantin    schedule 07.01.2012
comment
@JeffreyHantin Да, Джеффри, да. Вот почему я спросил, что точно сделал ОП.   -  person alf    schedule 07.01.2012
comment
Oracle JDK 6. Но я думаю, что лучше спросить, как вы говорите, что вам нужно столько памяти, сколько вам нужно?   -  person Stephane Grenier    schedule 09.01.2012
comment
@StephaneGrenier Стандартная JRE не может автоматически увеличивать кучу за счет выделения нового адресного пространства — она должна предварительно выделить всю кучу диапазон адресов (значение -Xmx), а отображает только фактические страницы ОЗУ и/или подкачки в это адресное пространство по мере необходимости (начиная со значения -Xms). Это ограничение реализации, возникающее в результате оптимизации — оно позволяет сборщику мусора обрабатывать всю кучу Java как один гигантский массив.   -  person Jeffrey Hantin    schedule 11.01.2012


Ответы (2)


Возможно, это связано с фрагментацией виртуального адресного пространства. Может оказаться невозможным зарезервировать непрерывный диапазон адресов размером 1024 МБ для максимального потенциального размера кучи, в зависимости от адресов загрузки библиотек DLL, расположения потоков в стеке, недвижимого собственного распределения памяти, зарезервированных адресов ядра и так далее, особенно в 32-битном процессе.

person Jeffrey Hantin    schedule 05.01.2012

Некоторое время назад я столкнулся с этой проблемой в Windows XP. На одной из большинства машин XP я мог выделить 1400 МБ, а на других — только 1200 МБ. Консенсус был фрагментирован, как говорит Джеффри Хантин в другом ответе.

person Steve Kuo    schedule 05.01.2012