Split heap (Windows only, deprecated)

Many Java™ application workloads depend on the Java heap size. The SDK can use a split heap to work around restrictions in the 32-bit Windows memory space and provide a larger maximum heap size. This feature can be useful for applications that must run on the 32-bit JVM (for example because of 32-bit JNI libraries, a 32-bit operating system, or 32-bit hardware) but need large Java heaps.

Note: The -Xgc:splitheap command-line option was deprecated in Version 8 and will be removed from future versions of the IBM SDK.

A break in the Windows address space limits the Java heap to less than 2 GB. Use a split heap to allow the Java heap to exist on both sides of the break in address space. You might be able to allocate a larger heap compared with the use of one contiguous area of memory. By using a larger heap, you can allocate more objects before incurring a garbage collection and you can increase the number of live objects that you can use before an OutOfMemoryError exception occurs.

Use the -Xgc:splitheap command-line option (available on the Windows 32-bit JVM only) to enable the split heap. When you use this option, the following behavior is also enabled:
  • The garbage collector is forced to use the gencon (generational concurrent) garbage collection policy.
  • The new and old areas of the generational Java heap are allocated in separate areas of memory.
  • Resizing of the new and old memory areas is disabled.
A split heap is not recommended if your application works in the any of the following ways:
  • Performs poorly under the gencon garbage collection policy.
  • Loads a very large number of classes.
  • Uses large amounts of native system memory in JNI libraries; the increased size Java heap might reserve too much of the application's address space.
Restriction: A Windows 32-bit process is limited to a 2 GB address space unless the /3GB option is specified in the boot.ini file. See Windows 32-bit large address aware support in the SDK user guide for more information.

With a split heap, the old area is committed to its maximum size (set with -Xmox) in a lower region of memory and the new area is committed to its maximum size (set with -Xmnx) in a higher region of memory.

Allocation failures

With a split heap the JVM can fail at startup in more ways. The following messages are caused by failure to allocate a split heap:
JVMJ9GC064 Failed to allocate old space
There is not enough free space in lower memory to allocate the old area. To resolve the problem, reduce -Xmox.
JVMJ9GC065 Failed to allocate new space
There is not enough free space in higher memory to allocate the new area. To resolve the problem, reduce -Xmnx.
JVMJ9GC066 Required split heap memory geometry could not be allocated
The new area was allocated lower than the old area. To resolve the problem, reduce -Xmx.

Maximum heap sizes

The typical maximum heap sizes are as follows:

Windows 7 32-bit on 32-bit hardware using the 32–bit JVM
1800 MiB old area and 1000 MiB new area.
-Xgc:splitheap -Xmx2800m -Xmox1800m
Windows 7 64-bit on 64-bit hardware using the 32–bit JVM
1700 MiB old area and 2000 MiB new area.
-Xgc:splitheap -Xmx3700m -Xmox1700m

Applications have lower limits if they load a large number of classes, load a large number of native libraries, or start several threads.