Heap expansion | Tuning the JVM heap size
Heap shrinkage
Heap shrinkage occurs after garbage collection (GC) while exclusive access of the virtual machine is still held.
Shrinkage does NOT occur if any of the following are true...
- The GC did not free enough space to satisfy the allocation request.
- The maximum free space, which can be set by the -Xmaxf parameter (default is 60%) is set to 100%.
- The heap has been expanded in the last three garbage collections.
- This is a System.gc(), and the amount of free space at the beginning of the garbage collection was less than -Xminf (default is 30%) of the live part of the heap.
- If none of the above is true and more than -Xmaxf free space exists, the GC must calculate how much to shrink the heap to get it to -Xmaxf free space, without going below the initial (-Xms) value. This figure is rounded down to a 256-byte boundary (512 bytes if concurrent mark is used) on 32-bit architecture, or a 1024 byte boundary on 64-bit architecture.
A compaction occurs before the shrink if all the following are true:
- A compaction was not done on this garbage collection cycle.
- No free chunk is at the end of the heap, or the size of the free chunk that is at the end of the heap is less than 10% of the required shrinkage amount.
- The GC did not shrink and compact on the last garbage collection cycle.
Note that, on initialization, the JVM allocates the entire heap in a single contiguous area of virtual storage. The amount that is allocated is determined by the setting of the -Xmx parameter. No virtual space from the heap is ever freed back to the native operating system. When the heap shrinks, it shrinks inside the original virtual space.
xxxx