Maximum Java heap size of a 32-bit JVM on a 64-bit OS

前端 未结 17 2188

The question is not about the maximum heap size on a 32-bit OS, given that 32-bit OSes have a maximum addressable memory size of 4GB, and that the JVM\'s max heap size depen

相关标签:
17条回答
  • 2020-11-22 07:01

    On Solaris the limit has been about 3.5 GB since Solaris 2.5. (about 10 years ago)

    0 讨论(0)
  • 2020-11-22 07:04

    The limitations of a 32-bit JVM on a 64-bit OS will be exactly the same as the limitations of a 32-bit JVM on a 32-bit OS. After all, the 32-bit JVM will be running In a 32-bit virtual machine (in the virtualization sense) so it won't know that it's running on a 64-bit OS/machine.

    The one advantage to running a 32-bit JVM on a 64-bit OS versus a 32-bit OS is that you can have more physical memory, and therefore will encounter swapping/paging less frequently. This advantage is only really fully realized when you have multiple processes, however.

    0 讨论(0)
  • 2020-11-22 07:04

    This is heavy tunning, but you can get a 3gb heap.

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

    0 讨论(0)
  • 2020-11-22 07:06

    You don't specify which OS.

    Under Windows (for my application - a long running risk management application) we observed that we could go no further than 1280MB on Windows 32bit. I doubt that running a 32bit JVM under 64bit would make any difference.

    We ported the app to Linux and we are running a 32bit JVM on 64bit hardware and have had a 2.2GB VM running pretty easily.

    The biggest problem you may have is GC depending on what you are using memory for.

    0 讨论(0)
  • 2020-11-22 07:07

    Here is some testing under Solaris and Linux 64-bit

    Solaris 10 - SPARC - T5220 machine with 32 GB RAM (and about 9 GB free)

    $ 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: Apparently Java does not allocate much actual memory with the startup. It seemed to take only about 100 MB per instance started (I started 10)

    Solaris 10 - x86 - VMWare VM with 8 GB RAM (about 3 GB free*)

    The 3 GB free RAM is not really true. There is a large chunk of RAM that ZFS caches use, but I don't have root access to check how much exactly

    $ 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 with 4 GB RAM (about 3.8 GB used - 200 MB in buffers and 3.1 GB in caches, so about 3 GB free)

    $ 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
    

    Same machine using 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
    
    0 讨论(0)
  • 2020-11-22 07:08

    Should be a lot better

    For a 32-bit JVM running on a 64-bit host, I imagine what's left over for the heap will be whatever unfragmented virtual space is available after the JVM, it's own DLL's, and any OS 32-bit compatibility stuff has been loaded. As a wild guess I would think 3GB should be possible, but how much better that is depends on how well you are doing in 32-bit-host-land.

    Also, even if you could make a giant 3GB heap, you might not want to, as this will cause GC pauses to become potentially troublesome. Some people just run more JVM's to use the extra memory rather than one giant one. I imagine they are tuning the JVM's right now to work better with giant heaps.

    It's a little hard to know exactly how much better you can do. I guess your 32-bit situation can be easily determined by experiment. It's certainly hard to predict abstractly, as a lot of things factor into it, particularly because the virtual space available on 32-bit hosts is rather constrained.. The heap does need to exist in contiguous virtual memory, so fragmentation of the address space for dll's and internal use of the address space by the OS kernel will determine the range of possible allocations.

    The OS will be using some of the address space for mapping HW devices and it's own dynamic allocations. While this memory is not mapped into the java process address space, the OS kernel can't access it and your address space at the same time, so it will limit the size of any program's virtual space.

    Loading DLL's depends on the implementation and the release of the JVM. Loading the OS kernel depends on a huge number of things, the release, the HW, how many things it has mapped so far since the last reboot, who knows...

    In summary

    I bet you get 1-2 GB in 32-bit-land, and about 3 in 64-bit, so an overall improvement of about 2x.

    0 讨论(0)
提交回复
热议问题