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

R

17

119

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 depends on how much contiguous free memory can be reserved.

I'm more interested in knowing the maximum (both theoretical and practically achievable) heap size for a 32-bit JVM running in a 64-bit OS. Basically, I'm looking at answers similar to the figures in a related question on SO.

As to why a 32-bit JVM is used instead of a 64-bit one, the reason is not technical but rather administrative/bureaucratic - it is probably too late to install a 64-bit JVM in the production environment.

Rapprochement answered 16/9, 2009 at 18:44 Comment(0)

S

77

32-bit JVMs which expect to have a single large chunk of memory and use raw pointers cannot use more than 4 Gb (since that is the 32 bit limit which also applies to pointers). This includes Sun and - I'm pretty sure - also IBM implementations. I do not know if e.g. JRockit or others have a large memory option with their 32-bit implementations.

If you expect to be hitting this limit you should strongly consider starting a parallel track validating a 64-bit JVM for your production environment so you have that ready for when the 32-bit environment breaks down. Otherwise you will have to do that work under pressure, which is never nice.

Edit 2014-05-15: Oracle FAQ:

The maximum theoretical heap limit for the 32-bit JVM is 4G. Due to various additional constraints such as available swap, kernel address space usage, memory fragmentation, and VM overhead, in practice the limit can be much lower. On most modern 32-bit Windows systems the maximum heap size will range from 1.4G to 1.6G. On 32-bit Solaris kernels the address space is limited to 2G. On 64-bit operating systems running the 32-bit VM, the max heap size can be higher, approaching 4G on many Solaris systems.

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

Sinner answered 16/9, 2009 at 19:7 Comment(18)

No work pressure here. I know that a 64-bit JVM should have been installed in the first place. But it got me thinking about how a 32-bit JVM would work in an environment with more resources at its disposal. – Rapprochement 16/9, 2009 at 19:18

Isn't it around 2GB becuase of the signednes? Or is that just the Sun JVM? – Stretcher 16/9, 2009 at 19:19

Pointers are not signed - it doesn't make sense to speak of negative memory locations. – Wintergreen 16/9, 2009 at 21:15

No, it is not 2GB because of signedness. However, part of the 4GB address space is reserved for the OS kernel. On normal consumer versions of Windows, the limit is 2GB. On Linux and server versions of Windows (32-bit) the limit is 3GB per process. – Wend 17/9, 2009 at 10:44

@Jesper, additionally this is platform dependent. It is the PC-architecture imposing this limit. – Wintergreen 21/3, 2012 at 12:28

@Wend I was wondering if a 32-bit JVM running on a 64-bit operating system could have a full 4 GB address space available? – Wintergreen 20/12, 2012 at 10:14

Would it be possible for a JVM to use a 32-bit object type, but specify that those 32 bits hold a value which is 1/8 of the "real" address, so that loading a word from offset 28 of a reference held in EBX would be mov eax,[ebx*8+28]? For projects that needed between 4GB and ~32GB of heap, that would seem more efficient than using bulky 64-bit references. – Mauldin 17/12, 2013 at 21:7

@Mauldin have a look at blogs.oracle.com/jrockit/entry/understanding_compressed_refer – Wintergreen 17/12, 2013 at 23:31

@ThorbjørnRavnAndersen: Cool. I've for a long time thought Intel's 8086 addressing scheme was unfairly maligned. A mode where segment registers were simply shifted 4 places and added to an offset would be great for an object-oriented framework; it could be made even better if the upper part of the segment register was used to select among configurable addressing areas with different scale factors. Have one part of memory for small objects, with a scale factor of 8, and another for medium objects with a scale factor of 64, and one for big objects with a scale factor of 256. – Mauldin 17/12, 2013 at 23:46

@Mauldin you need to take garbage collection into consideration. What you suggest essentially mean that you introduce several new separate memory areas where objects cannot easily migrate from one to another, making garbage collection much more complex. – Wintergreen 17/12, 2013 at 23:50

@ThorbjørnRavnAndersen: There would be separate areas heap optimized for different sizes of objects, but I wouldn't see any obstacle to objects moving among them. One would have more space in large-grained areas than small-grained ones, so one would prefer to put objects that wouldn't benefit from smaller-grained areas into larger-grained ones when practical; further, the loss of an average of e.g. 128 bytes per allocation in the large grained area would mean one should prefer to avoid using it for objects where that loss would be significant, but... – Mauldin 17/12, 2013 at 23:59

...shouldn't have any objection to using it for objects that are e.g. 4K or larger in size. – Mauldin 18/12, 2013 at 0:2

@Mauldin I would suggest you look into the various research papers about garbage collection where I am certain your suggestion has been thought of and analyzed. My guess is that the janitor work needed makes it less interesting than other approaches. – Wintergreen 10/7, 2014 at 9:56

I found most of Windows 7 installed 32bit jre in my company can not use 1.4G memory. So just do not rely on what Oracle said if you want to use as much memory as possible. – Uniocular 5/7, 2015 at 6:57

@Uniocular you need enough RAM to support giving the JVM the additional memory (i.e. enough swap). – Wintergreen 5/7, 2015 at 15:26

@ThorbjørnRavnAndersen In my 64bit windows7 with 64bit jre. I can set -Xmx600G, but I have only 16GB RAM installed on my PC. – Uniocular 6/7, 2015 at 1:56

@Uniocular try to add -XX:+AlwaysPreTouch, what you are requesting is virtual space, as soon as you enable that key - it will fail. – Nadanadab 2/5, 2020 at 3:7

kernel address space usage seems to have the biggest impact – Nadanadab 2/5, 2020 at 3:35

C

96

You can ask the 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)");
    }
}

This will report the "Max Memory" based upon default heap allocation. So you still would need to play with -Xmx (on HotSpot). I found that running on Windows 7 Enterprise 64-bit, my 32-bit HotSpot JVM can allocate up to 1577MiB:

[C:scratch]> java -Xmx1600M MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
[C:scratch]> java -Xmx1590M MaxMemory
Total Memory: 2031616 (1.9375 MiB)
Max Memory:   1654456320 (1577.8125 MiB)
Free Memory:  1840872 (1.75559234619 MiB)
[C:scratch]>

Whereas with a 64-bit JVM on the same OS, of course it's much higher (about 3TiB)

[C:scratch]> java -Xmx3560G MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
[C:scratch]> java -Xmx3550G MaxMemory
Total Memory: 94240768 (89.875 MiB)
Max Memory:   3388252028928 (3184151.84297 MiB)
Free Memory:  93747752 (89.4048233032 MiB)
[C:scratch]>

As others have already mentioned, it depends on the OS.

For 32-bit Windows: it'll be <2GB (Windows internals book says 2GB for user processes)
For 32-bit BSD / Linux: <3GB (from the Devil Book)
For 32-bit MacOS X: <4GB (from Mac OS X internals book)
Not sure about 32-bit Solaris, but the code above has been tested in this answer.

For a 64-bit host OS, if the JVM is 32-bit, it'll still depend, most likely like above as demonstrated.

-- UPDATE 20110905: I just wanted to point out some other observations / details:

The hardware that I ran this on was 64-bit with 6GB of actual RAM installed. The operating system was Windows 7 Enterprise, 64-bit
The actual amount of Runtime.MaxMemory that can be allocated also depends on the operating system's working set. I once ran this while I also had VirtualBox running and found I could not successfully start the HotSpot JVM with -Xmx1590M and had to go smaller. This also implies that you may get more than 1590M depending upon your working set size at the time (though I still maintain it'll be under 2GiB for 32-bit because of Windows' design)

Chloromycetin answered 11/8, 2011 at 0:44 Comment(12)

I like that you actually tested rather than made guesses. – Revoke 25/8, 2011 at 18:1

Hard to believe that a 32-bit hotspot JVM says it has 15GB free. I don't believe it. It makes no sense. – Matrona 25/8, 2011 at 21:21

@Matrona is right. The program should be dividing by 1,048,576 (1024*1024, or 2^20), not 104,856. But, that's just a display thing. As you can see from the command, he only tried to set the maximum heap size to 1,590 MiB. – Revoke 29/8, 2011 at 12:14

Oops, yeah, transcription error from my calculator: 1024*1024 = 1048576. Sorry I missed the 7 :) I'll edit above and re-run... – Chloromycetin 2/9, 2011 at 6:7

Very cool answer (I would like to say the answer), with a code example, and details covering all OSes. – Bonni 17/6, 2013 at 21:42

Following up to my previous comment: The jdocs (for windows atleast) specify that the -Xmx and -Xms paramters must be given a value that is a multiple of 1024... I'm not sure if 1590 is, so I think strange results should be expected. – Bonni 17/6, 2013 at 22:1

Well spotted TGP1994. I think that, because I've specified 'M' and 'G' multiples, then the size (in bytes) will work out to be a multiple of 1024 bytes anyway. e.g. 1590M will be parsed to 1590*(1024*1024) = 1667235840 bytes (1628160KiB -- an even multiple of 1024 of course). – Chloromycetin 19/6, 2013 at 0:5

For me it seems to massively fluctuate, presumably depending on the exact memory partitioning of running apps (i.e., the working set). I have situations with 4.5GB RAM free (on Win 10 x64) and yet I can only allocate 1012MB or 1024MB heap space. Is there no more detailed information/explanation of this from Oracle or similar? – Perish 13/4, 2016 at 10:32

In my blog from 2007 (9 years ago!) I added an update, with some very good info from this SO question and this excellent blog article by Dhamvir Singh. Recommend you read his post for more detail. – Chloromycetin 15/4, 2016 at 11:24

You should be able to do 2^64 bits of allocation even if RAM is exceeded in JVM x 64. – Hemorrhoid 27/6, 2016 at 17:2

@AndrewScottEvans well, not really, no. Most 64-bit OSes don't allow 18 exabyte (16 exbibyte) allocations even in virtual memory, even if they had the swap to support that. It's impractical from an OS design point -- even supercomputers are limited to hundreds of gigabytes of RAM and tens, perhaps hundreds of petabytes of online storage! The address space is better used for other purposes. Anyway the program in my answer demonstrates the difference between theory and practice.... – Chloromycetin 29/6, 2016 at 0:32

I am using Oracle Java version 1.8.0_231 Windows 10 and am getting between 1400 and 1590 MB. It seems to always work with 1400 but not consistently at 1500 MB and above. Note: I have 16GB RAM, of which only 46% is used. – Gemmulation 29/4, 2020 at 11:56