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


107

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

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

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

Ответы:


70

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 )


Здесь нет рабочего давления. Я знаю, что в первую очередь нужно было установить 64-битную JVM. Но это заставило меня задуматься о том, как 32-битная JVM будет работать в среде с большим количеством ресурсов в ее распоряжении.
Vineet Reynolds,

1
Разве это не около 2 ГБ из-за подписей? Или это просто Sun JVM?
Себастьян Гансландт

9
Указатели не подписаны - об отрицательных ячейках памяти говорить не имеет смысла.
Thorbjørn Ravn Andersen

12
Нет, это не 2 ГБ из-за подписи. Однако часть адресного пространства 4 ГБ зарезервирована для ядра ОС. В обычных потребительских версиях Windows ограничение составляет 2 ГБ. В Linux и серверных версиях Windows (32-разрядных) ограничение составляет 3 ГБ на процесс.
Jesper

3
@Jesper Мне было интересно, может ли 32-разрядная JVM, работающая в 64-разрядной операционной системе, иметь доступное целое 4 ГБ адресного пространства?
Торбьёрн Равн Андерсен

90

Вы можете спросить у 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)

13
Мне нравится, что вы на самом деле тестировали, а не делали предположения.
Джим Хёрн

3
@djangofan прав. Программа должна быть разделена на 1048576 (1024 * 1024 или 2 ^ 20), а не на 104856. Но это всего лишь демонстрация. Как видно из команды, он всего лишь попытался установить максимальный размер кучи равным 1590 МБ.
Джим Хёрн

1
Очень охладиться ответ (я хотел бы сказать в ответ), с примером кода, а также деталью , охватывающая все операционками.
TGP1994

3
Следуя моему предыдущему комментарию: jdocs (по крайней мере для окон) указывает, что параметрам -Xmx и -Xms должно быть присвоено значение, кратное 1024 ... Я не уверен, что 1590, поэтому я считаю странным результатов следует ожидать.
TGP1994

4
Хорошо подмеченный TGP1994. Я думаю, что, поскольку я указал кратные «M» и «G», размер (в байтах) в любом случае будет кратным 1024 байтам. например, 1590M будет проанализировано как 1590 * (1024 * 1024) = 1667235840 байт (1628160KiB - разумеется, кратное 1024).
Майк

16

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

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

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

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


Я бы предпочел знать ограничение для Solaris 10, но тогда это касается только моей проблемы. Хотел бы знать и о других ОС, на черный день :)
Винит Рейнольдс

Не уверен насчет Соляриса. Я ожидал, что размер виртуальной машины будет довольно большим, мой опыт работы с Java на Solaris был несколько лет назад. И будучи виртуальной машиной Sun на ОС Sun на оборудовании Sun, все работало очень хорошо. Я также был убежден, что проблем с сборкой мусора в Solaris было меньше, чем в Linux / Windows.
Fortyrunner

Какая именно винда была. Я считаю, что серверные версии 32-битной Windows намного лучше справляются с большими объемами памяти.
Thorbjørn Ravn Andersen

Ах, напоследок упоминание об ОС ;-) У вас установлено 64-битное ядро?
Thorbjørn Ravn Andersen

Это был сервер Win2k. Переходить на Win2k3 (все идет медленно ...) было слишком поздно, и вместо этого мы перешли на Linux.
Fortyrunner

14

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

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

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


12

У нас недавно был некоторый опыт в этом. Недавно мы перенесли 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 МБ).


Причина ответа службы поддержки заключается в том, сколько адресуемой памяти доступно процессу. Это зависит от ядра Linux и даже от оборудования. Теоретически адресуемая память ограничена 2 ^ 32 = 4G (и размер кучи Java будет меньше этого). Но это может (теоретически) быть расширено с помощью hugemem и PAE; Я не пробовал этого.
Vineet Reynolds

9

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

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


1
Может быть небольшая разница в зависимости от оборудования и способа его виртуализации. Часть адресного пространства 4 ГБ обычно используется для устройств с отображением памяти. Уровень виртуализации может иметь или не иметь такой же объем памяти, что и физические устройства на машине.
Эрик Дж.

8
Не совсем. На 64-битной машине больше места для JVM, поскольку 32-битное адресное пространство не обязательно должно использоваться совместно с операционной системой или аппаратными интерфейсами.
Торбьёрн Равн Андерсен

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

Торбьёрн: операционная система и аппаратные интерфейсы по-прежнему необходимо сопоставить с 32-разрядной виртуальной машиной. Точное количество подслушанного может быть другим, но оно все равно будет. Если вы можете виртуализировать его под 64-битной ОС, что мешает вам виртуализировать его под 32-битной ОС? Это виртуальная память , мы говорим о.
Лоуренс Гонсалвес,

2
LG: Я не согласен с вашим первоначальным ответом. Ядро ОС и любое отображаемое им аппаратное и шинное адресное пространство будут занимать большую часть адресного пространства, и хотя оно не отображается в пользовательской программе, оно действительно уменьшает количество, «оставшееся» после того, как ОС настроилась. Это значительный объем 32-битного пространства размером 4 ГБ. Традиционно это означало, что примерно 25–75% из 4 ГБ недоступны для пользовательских процессов. :-) Ядерный хакер
DigitalRoss

6

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

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

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

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

.


Приятно, что вы дали совет из первых рук, бывший сотрудник BEA :)
emecas

4

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


4

Вот некоторые тесты под 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

Здесь есть несколько полезных результатов тестов для платформ, которые нам не хватало. Хорошая работа с использованием файловых дампов и дампов памяти.
Майк

3

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

Для 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 раза .


1
К сожалению, в моем распоряжении нет 64-битной среды, в которой я мог бы поэкспериментировать с флагом Xmx. Тот, о котором я знаю, имеет огромный (32 * n) объем доступной оперативной памяти, но за пределами возможностей. Вот почему я хотел знать, как 32-битная JVM будет работать без всех ограничений, с которыми она обычно сталкивается в 32-битном мире.
Vineet Reynolds,

Что ж, хороший вопрос. Я уверен, что основной ответ - «так будет лучше».
DigitalRoss,

Хорошо, я отредактировал свой ответ, чтобы сосредоточиться на вашем реальном вопросе. :-)
DigitalRoss

1
≅ 3 ГБ в 64-битном формате звучат как раз. Торбьёрн уже указал, почему теоретически он не может превышать 4 ГБ. Жаль, что я не могу принять два ответа.
Vineet Reynolds,

Если у вас большой компьютер , вы можете поэкспериментировать с 64-битным Solaris, например, в виртуальном боксе (который имеет лучшую гостевую поддержку Solaris).
Thorbjørn Ravn Andersen

2

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


Я собираюсь поэкспериментировать с этим, используя Oracle Solaris Express 11.
djangofan

1
@Peter Lawrey Эм ... Solaris 2.5 был почти 20 лет назад, если учесть дату выпуска в мае 1996 года .... конечно, он не закончился примерно до 2005 года.
cb88

1

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

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

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

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


0

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


Я подумал, что добавлю, что в 64-битной Windows VISTA 32-битная JVM имеет максимальную длину 1582 м (значение -Xmx). Будет жаловаться, если я укажу 1583м. Я не знаю, меняется ли это значение от машины к машине. Компьютер, на котором я это тестировал, фактически имел 4 ГБ физической памяти.
Сантош Тивари

@SantoshTiwari он меняется от машины к машине, но вот почему
Евгений


0

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

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


0

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

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

0000....0001

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

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

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


-1

Теоретически 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.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.