(Windows™ 32-bit only)
By default, the VM uses a contiguous Java™ heap to store Java objects. However, on Windows 32-bit systems, there are restrictions in the 32-bit memory space that prevents a process accessing more than 2GB of memory, even if there is more memory available. To increase the maximum allocatable heap size, OpenJ9 can split the heap, allowing memory use up to the 4GB limit.
- A split heap forces the Garbage Collector to use the
genconpolicy and allocates the new and old areas of the generational Java heap in separate areas of memory. Resizing of the new and old memory areas is disabled.
- This option can be used only with Java SE version 8 runtime environments. This option is deprecated in Version 8 and will be removed from future versions.
-Xgc:splitheap for applications that must run on the 32-bit VM because of 32-bit JNI libraries, a 32-bit operating system, or 32-bit hardware, but need large Java heaps. 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.
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.
This option 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.