Java Reference
In-Depth Information
Table 5-4. Default heap sizes
Operating system and
JVM
Initial heap (Xms)
Maximum heap (Xmx)
Linux/Solaris, 32-bit client
16 MB
256 MB
Linux/Solaris, 32-bit server
64 MB
Min (1 GB, 1/4 of physical
memory)
Linux/Solaris, 64-bit server
Min (512 MB, 1/64 of physical
memory)
Min (32 GB, 1/4 of physical
memory)
MacOS 64-bit server JVMs
64 MB
Min (1 GB, 1/4 of physical
memory)
Windows 32-bit client JVMs 16 MB
256 MB
Windows 64-bit server JVMs 64 MB
Min (1 GB, 1/4 of physical
memory)
On a machine with less than 192 MB of physical memory, the maximum heap size will be
half of the physical memory (96 MB or less).
Having an initial and maximum size for the heap allows the JVM to tune its behavior de-
pending on the workload. If the JVM sees that it is doing too much GC with the initial heap
size, it will continually increase the heap until the JVM is doing the “correct” amount of GC,
or until the heap hits its maximum size.
For many applications, that means a heap size doesn't need to be set at all. Instead, you spe-
cify the performance goals for the GC algorithm: the pause times you are willing to tolerate,
the percentage of time you want to spend in GC, and so on. The details of that will depend
on the GC algorithm used and are discussed in the next chapter (though even then, the de-
faults are chosen such that for a wide range of applications, those values needn't be tuned
either).
That approach usually works fine if an application does not need a larger heap than the de-
fault maximum for the platform it is running on. However, if the application is spending too
much time in GC, then the heap size will need to be increased by setting the -Xmx flag. There
is no hard-and-fast rule on what size to choose (other than not specifying a size larger than
the machine can support). A good rule of thumb is to size the heap so that it is 30% occupied
after a full GC. To calculate this, run the application until it has reached a steady-state con-
Search WWH ::




Custom Search