Максимальный размер кучи Java 32-разрядной JVM в 64-разрядной ОС

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

Меня больше интересует максимальный (как теоретический, так и практически достижимый) размер кучи для 32-разрядной JVM, работающей в 64-разрядной ОС. В принципе, я ищу ответы, аналогичные цифрам в соответствующем вопросе по SO .

Что касается того, почему 32-битная JVM используется вместо 64-битной, то причина не техническая, а скорее административная / бюрократическая - вероятно, уже слишком поздно устанавливать 64-битную JVM в производственной среде.

32-битные JVM, которые рассчитывают иметь один большой кусок памяти и используют необработанные указатели, не могут использовать более 4 Гб (поскольку это 32-битный предел, который также применяется к указателям). Это включает в себя Sun и - я почти уверен - также реализации IBM. Я не знаю, есть ли у JRockit или других большой объем памяти в их 32-битных реализациях.

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

Изменить 2014-05-15: Oracle FAQ:

Максимальный теоретический предел кучи для 32-разрядной JVM составляет 4G. Из-за различных дополнительных ограничений, таких как доступный своп, использование адресного пространства ядра, фрагментация памяти и накладные расходы виртуальной машины, на практике предел может быть намного ниже. В большинстве современных 32-разрядных систем Windows максимальный размер кучи составляет от 1,4 ГБ до 1,6 ГБ. В 32-разрядных ядрах Solaris адресное пространство ограничено 2 ГБ. В 64-разрядных операционных системах, на которых работает 32-разрядная виртуальная машина, максимальный размер кучи может быть выше, приближаясь к 4G во многих системах Solaris.

( http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit )

Вы можете спросить у Java Runtime:

public class MaxMemory {
    public static void main(String[] args) {
        Runtime rt = Runtime.getRuntime();
        long totalMem = rt.totalMemory();
        long maxMem = rt.maxMemory();
        long freeMem = rt.freeMemory();
        double megs = 1048576.0;

        System.out.println ("Total Memory: " + totalMem + " (" + (totalMem/megs) + " MiB)");
        System.out.println ("Max Memory:   " + maxMem + " (" + (maxMem/megs) + " MiB)");
        System.out.println ("Free Memory:  " + freeMem + " (" + (freeMem/megs) + " MiB)");
    }
}

Это сообщит «Макс. Объем памяти» на основе распределения кучи по умолчанию. Так что вам все равно придется поиграть -Xmx(на HotSpot ). Я обнаружил, что при работе в 64-разрядной версии Windows 7 Enterprise моя 32-разрядная JVM HotSpot может выделить до 1577 МБ:

[C: scratch]> java -Xmx1600M MaxMemory
Ошибка при инициализации ВМ
Не удалось зарезервировать достаточно места для кучи объектов
Не удалось создать виртуальную машину Java.
[C: царапина]> java -Xmx1590M MaxMemory
Общий объем памяти: 2031616 (1,9375 МБ)
Макс.память: 1654456320 (1577,8125 МиБ)
Свободная память: 1840872 (1.75559234619 МиБ)
[C: царапина]>

В то время как с 64-битной JVM в той же ОС, конечно, намного больше (около 3 ТиБ)

[C: царапина]> java -Xmx3560G MaxMemory
Ошибка при инициализации ВМ
Не удалось зарезервировать достаточно места для кучи объектов
[C: scratch]> java -Xmx3550G MaxMemory
Общий объем памяти: 94240768 (89,875 МиБ)
Макс.память: 3388252028928 (3184151,84297 МиБ)
Свободная память: 93747752 (89,4048233032 МиБ)
[C: царапина]>

Как уже упоминалось, это зависит от ОС.

• Для 32-битной Windows: это будет <2 ГБ (в книге о внутреннем устройстве Windows указано 2 ГБ для пользовательских процессов)
• Для 32-битной BSD / Linux: <3 ГБ (из книги дьявола)
• Для 32-разрядной MacOS X: <4 ГБ (из внутренней книги Mac OS X )
• Не уверены насчет 32-битного Solaris, попробуйте приведенный выше код и сообщите нам.

Для 64-разрядной ОС хоста, если JVM 32-разрядная, она все равно будет зависеть, скорее всего, как показано выше.

- ОБНОВЛЕНИЕ 20110905 : Я просто хотел указать на некоторые другие наблюдения / детали:

• Аппаратное обеспечение, на котором я запускал это, было 64-битным с 6 ГБ оперативной памяти. Операционная система Windows 7 Enterprise, 64-разрядная.
• Фактическая сумма, Runtime.MaxMemoryкоторую можно выделить, также зависит от рабочего набора операционной системы . Однажды я запустил это, когда у меня также был запущен VirtualBox, и обнаружил, что не могу успешно запустить JVM HotSpot, и мне -Xmx1590Mпришлось уменьшить размер. Это также означает, что вы можете получить более 1590 МБ в зависимости от размера вашего рабочего набора в то время (хотя я по-прежнему утверждаю, что для 32-разрядной версии это будет менее 2 ГБ из-за дизайна Windows)

Вы не указываете, какая ОС.

Под Windows (для моего приложения - давно работающего приложения для управления рисками) мы заметили, что мы не можем пойти дальше 1280 МБ на 32-битной Windows. Я сомневаюсь, что запуск 32-битной JVM под 64-битной версией будет иметь какое-то значение.

Мы портировали приложение на Linux, и мы запускаем 32-битную JVM на 64-битном оборудовании, и у нас довольно легко работает виртуальная машина 2,2 ГБ.

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

Из 4.1.2 Размер кучи :

«Для 32-разрядной модели процесса максимальный размер виртуального адреса процесса обычно составляет 4 ГБ, хотя некоторые операционные системы ограничивают его до 2 ГБ или 3 ГБ. Максимальный размер кучи обычно составляет -Xmx3800 м (1600 м) для ограничений в 2 ГБ. ), хотя фактическое ограничение зависит от приложения. Для 64-битных моделей процессов максимум практически неограничен ».

Нашел здесь довольно хороший ответ: максимальная память Java в Windows XP .

У нас недавно был некоторый опыт в этом. Недавно мы перенесли Solaris (x86-64 версии 5.10) на Linux (RedHat x86-64) и поняли, что у нас меньше памяти для 32-битного процесса JVM в Linux, чем у Solaris.

Для Solaris это почти 4 ГБ (http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit).

Мы запускали наше приложение с -Xms2560m -Xmx2560m -XX: MaxPermSize = 512m -XX: PermSize = 512m без каких-либо проблем на Solaris в течение последних нескольких лет. Пытался переместить его в Linux, и у нас возникли проблемы со случайными ошибками нехватки памяти при запуске. Мы могли только заставить его постоянно запускаться на -Xms2300 -Xmx2300 . Потом нам об этом сообщили в службе поддержки.

32-разрядный процесс в Linux имеет максимальное адресное адресное пространство 3 ГБ (3072 МБ), тогда как в Solaris это полные 4 ГБ (4096 МБ).

Ограничения 32-битной JVM в 64-битной ОС будут точно такими же, как ограничения 32-битной JVM в 32-битной ОС. В конце концов, 32-битная JVM будет работать на 32-битной виртуальной машине (в смысле виртуализации), поэтому она не будет знать, что она работает на 64-битной ОС / машине.

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

Что касается того, почему используется 32-битная JVM вместо 64-битной, то причина не в технической, а в административной / бюрократической ...

Когда я работал в BEA, мы обнаружили, что среднее приложение на самом деле работает медленнее в 64-битной JVM, чем при работе в 32-битной JVM. В некоторых случаях снижение производительности было на 25% медленнее. Итак, если вашему приложению действительно не нужна вся эта дополнительная память, вам лучше установить больше 32-битных серверов.

Насколько я помню, три наиболее распространенных технических обоснования использования 64-битной системы, с которыми столкнулись специалисты BEA по оказанию профессиональных услуг, были:

1. Приложение манипулировало несколькими массивными изображениями,
2. Приложение выполняло массовую обработку чисел,
3. В приложении произошла утечка памяти, заказчик был главным по государственному контракту, и они не хотели тратить время и деньги на отслеживание утечки памяти. (Использование огромной кучи памяти увеличит MTBF, и основная сумма все равно будет оплачиваться)

.

JROCKIT JVM, в настоящее время принадлежащая Oracle, поддерживает использование несмежной кучи, что позволяет 32-битной JVM получать доступ к более чем 3,8 ГБ памяти, когда JVM работает в 64-битной ОС Windows. (2,8 ГБ при работе в 32-битной ОС).

http://blogs.oracle.com/jrockit/entry/how_to_get_almost_3_gb_heap_on_windows

JVM можно бесплатно загрузить (требуется регистрация) по адресу

http://www.oracle.com/technetwork/middleware/jrockit/downloads/index.html

Вот некоторые тесты под Solaris и Linux 64-bit

Solaris 10 - SPARC - машина T5220 с 32 ГБ ОЗУ (и около 9 ГБ свободно)

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3750m MaxMemory
Error occurred during initialization of VM
Could not reserve space for ObjectStartArray
$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3700m MaxMemory
Total Memory: 518520832 (494.5 MiB)
Max Memory:   3451912192 (3292.0 MiB)
Free Memory:  515815488 (491.91998291015625 MiB)
Current PID is: 28274
Waiting for user to press Enter to finish ...

$ java -version
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) Server VM (build 20.5-b03, mixed mode)

$ which java
/usr/bin/java
$ file /usr/bin/java
/usr/bin/java: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped, no debugging information available

$ prstat -p 28274
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
28274 user1     670M   32M sleep   59    0   0:00:00 0.0% java/35

BTW: Очевидно, Java не выделяет много фактической памяти при запуске. Казалось, что на запуск каждого экземпляра требовалось всего около 100 МБ (я запускал 10)

Solaris 10 - x86 - VMWare VM с 8 ГБ ОЗУ (около 3 ГБ свободно *)

Свободная оперативная память 3 ГБ - это не совсем так. Кэш ZFS использует большой кусок ОЗУ, но у меня нет доступа root, чтобы проверить, сколько именно

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3650m MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3600m MaxMemory
Total Memory: 516423680 (492.5 MiB)
Max Memory:   3355443200 (3200.0 MiB)
Free Memory:  513718336 (489.91998291015625 MiB)
Current PID is: 26841
Waiting for user to press Enter to finish ...

$ java -version
java version "1.6.0_41"
Java(TM) SE Runtime Environment (build 1.6.0_41-b02)
Java HotSpot(TM) Server VM (build 20.14-b01, mixed mode)

$ which java
/usr/bin/java

$ file /usr/bin/java
/usr/bin/java:  ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, no debugging information available

$ prstat -p 26841
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
26841 user1     665M   22M sleep   59    0   0:00:00 0.0% java/12

RedHat 5.5 - x86 - VMWare VM с 4 ГБ ОЗУ (используется около 3,8 ГБ - 200 МБ в буферах и 3,1 ГБ в кэше, поэтому около 3 ГБ свободно)

$ alias java='$HOME/jre/jre1.6.0_34/bin/java'

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3500m MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3450m MaxMemory
Total Memory: 514523136 (490.6875 MiB)
Max Memory:   3215654912 (3066.6875 MiB)
Free Memory:  511838768 (488.1274871826172 MiB)
Current PID is: 21879
Waiting for user to press Enter to finish ...

$ java -version
java version "1.6.0_34"
Java(TM) SE Runtime Environment (build 1.6.0_34-b04)
Java HotSpot(TM) Server VM (build 20.9-b04, mixed mode)

$ file $HOME/jre/jre1.6.0_34/bin/java
/home/user1/jre/jre1.6.0_34/bin/java: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped

$ cat /proc/21879/status | grep ^Vm
VmPeak:  3882796 kB
VmSize:  3882796 kB
VmLck:         0 kB
VmHWM:     12520 kB
VmRSS:     12520 kB
VmData:  3867424 kB
VmStk:        88 kB
VmExe:        40 kB
VmLib:     14804 kB
VmPTE:        96 kB

Та же машина с JRE 7

$ alias java='$HOME/jre/jre1.7.0_21/bin/java'

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3500m MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3450m MaxMemory
Total Memory: 514523136 (490.6875 MiB)
Max Memory:   3215654912 (3066.6875 MiB)
Free Memory:  511838672 (488.1273956298828 MiB)
Current PID is: 23026
Waiting for user to press Enter to finish ...

$ java -version
java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) Server VM (build 23.21-b01, mixed mode)

$ file $HOME/jre/jre1.7.0_21/bin/java
/home/user1/jre/jre1.7.0_21/bin/java: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

$ cat /proc/23026/status | grep ^Vm
VmPeak:  4040288 kB
VmSize:  4040288 kB
VmLck:         0 kB
VmHWM:     13468 kB
VmRSS:     13468 kB
VmData:  4024800 kB
VmStk:        88 kB
VmExe:         4 kB
VmLib:     10044 kB
VmPTE:       112 kB

Должно быть намного лучше

Для 32-битной JVM, работающей на 64-битном хосте, я полагаю, что то, что останется для кучи, будет любым нефрагментированным виртуальным пространством, доступным после JVM, собственной DLL и любыми 32-битными материалами совместимости с ОС. Как дикое предположение, я бы подумал, что 3 ГБ должно быть возможно, но насколько это лучше, зависит от того, насколько хорошо вы справляетесь с 32-битным хостом.

Кроме того, даже если вы могли бы создать гигантскую кучу 3 ГБ, вы, возможно, не захотите, так как это приведет к тому, что паузы сборщика мусора станут потенциально неприятными. Некоторые люди просто запускают больше JVM, чтобы использовать дополнительную память, а не одну гигантскую. Я предполагаю, что прямо сейчас они настраивают JVM, чтобы лучше работать с гигантскими кучами.

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

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

Загрузка DLL зависит от реализации и выпуска JVM. Загрузка ядра ОС зависит от огромного количества вещей, от выпуска, HW, от того, сколько вещей было сопоставлено с момента последней перезагрузки, кто знает ...

В итоге

Бьюсь об заклад, вы получите 1-2 ГБ в 32-битной среде и около 3 в 64-битной, так что общее улучшение примерно в 2 раза .

В Solaris ограничение составляет около 3,5 ГБ, начиная с версии Solaris 2.5. (около 10 лет назад)

У меня были те же проблемы с JVM, которые использует App Inventor для Android Blocks Editor. Максимальный размер кучи составляет 925 м. Этого недостаточно, но я не мог установить его больше, чем около 1200 м, в зависимости от различных случайных факторов на моей машине.

Я загрузил Nightly, бета-версию 64-битного браузера из Firefox, а также 64-битную версию JAVA 7.

Я еще не нашел свой новый предел кучи, но я только что открыл JVM с размером кучи 5900 м . Нет проблем!

Я использую 64-разрядную версию Win 7 Ultimate на машине с 24 ГБ ОЗУ.

Я попытался установить размер кучи до 2200 МБ на 32-битной машине Linux, и JVM работала нормально. JVM не запускалась, когда я установил ее на 2300M.

Это тяжеловесный тюнинг, но можно получить кучу 3гб.

http://www.microsofttranslator.com/bv.aspx?from=&to=en&a=http://forall.ru-board.com/egor23/online/FAQ/Virtual_Memory/Limits_Virtual_Memory.html

еще один момент для точки доступа 32-битной JVM: - собственная емкость кучи = 4 гигабайта - Java Heap - PermGen;

Это может стать особенно сложно для 32-разрядной JVM, поскольку Java Heap и собственная Heap находятся в гонке. Чем больше ваша Java Heap, тем меньше собственная Heap. Попытка настроить большую кучу для 32-разрядной виртуальной машины, например. 2,5 ГБ + увеличивает риск возникновения ошибки OutOfMemoryError в зависимости от занимаемой площади вашего приложения, количества потоков и т. Д.

Ограничение также связано с тем, что для 32 bitвиртуальной машины heapона должна начинаться с нулевого адреса, если вы хотите все это 4GB.

Подумайте об этом, если вы хотите ссылаться на что-то через:

0000....0001

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

    | ....               .... {heap_start .... heap_end} ... |
 --> (this can't be referenced) <--

Поскольку куча никогда не начинается с нулевого адреса в файле OS, существует довольно много битов, которые никогда не используются из 32ссылки на биты, и поэтому куча, на которую можно ссылаться, меньше.

Теоретически 4 ГБ, но на практике (для IBM JVM):

Win 2k8 64, IBM Websphere Application Server 8.5.5 32 бит

C:\IBM\WebSphere\AppServer\bin>managesdk.bat -listAvailable -verbose CWSDK1003I: Доступные SDK: CWSDK1005I: Имя SDK: 1.6_32 - com.ibm.websphere.sdk.version.1.6_32=1.6 - com.ibm.websphere.sdk.bits.1.6_32=32 - com.ibm.websphere.sdk.location.1.6_32=${WAS_INSTALL_ROOT}/java - com.ibm.websphere.sdk.platform.1.6_32=windows - com.ibm.websphere.sdk.architecture.1.6_32=x86_32 - com.ibm.websphere.sdk.nativeLibPath.1.6_32=${WAS_INSTALL_ROOT}/lib/native/win /x86_32/ CWSDK1001I: Задача managesdk выполнена успешно. C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2036 MaxMemory JVMJ9GC017E -Xmx слишком мала, должна быть не меньше 1 M байт JVMJ9VM015W Ошибка инициализации для библиотеки j9gc26(2): Не удалось инициализи ровать Could not create the Java virtual machine. C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2047M MaxMemory Total Memory: 4194304 (4.0 MiB) Max Memory: 2146435072 (2047.0 MiB) Free Memory: 3064536 (2.9225692749023438 MiB) C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2048M MaxMemory JVMJ9VM015W Ошибка инициализации для библиотеки j9gc26(2): Не удалось создать эк земпляр кучи; запрошено 2G Could not create the Java virtual machine.

RHEL 6.4 64, IBM Websphere Application Server 8.5.5 32 бит

[bin]./java -Xmx3791M MaxMemory Total Memory: 4194304 (4.0 MiB) Max Memory: 3975151616 (3791.0 MiB) Free Memory: 3232992 (3.083221435546875 MiB) [root@nagios1p bin]# ./java -Xmx3793M MaxMemory Total Memory: 4194304 (4.0 MiB) Max Memory: 3977248768 (3793.0 MiB) Free Memory: 3232992 (3.083221435546875 MiB) [bin]# /opt/IBM/WebSphere/AppServer/bin/managesdk.sh -listAvailable -verbose CWSDK1003I: Available SDKs : CWSDK1005I: SDK name: 1.6_32 - com.ibm.websphere.sdk.version.1.6_32=1.6 - com.ibm.websphere.sdk.bits.1.6_32=32 - com.ibm.websphere.sdk.location.1.6_32=${WAS_INSTALL_ROOT}/java - com.ibm.websphere.sdk.platform.1.6_32=linux - com.ibm.websphere.sdk.architecture.1.6_32=x86_32 -com.ibm.websphere.sdk.nativeLibPath.1.6_32=${WAS_INSTALL_ROOT}/lib/native/linux/x86_32/ CWSDK1001I: Successfully performed the requested managesdk task.