Largest Possible Maximum Heap Size for WebSphere Java 64 Bit on Linux x86-64
DavidLaraman 270004BMB2 Visits (573)
Java on Linux x86-64 supports 48-bit pointers and 256 TB of virtual address space, of which 128 terabytes is reserved for the Kernel, and 128 terabytes for User space.
Maximum Heap in theory on WAS Linux x86-64 would be -Xmx128t with the caveat or requirement of havi
Maximum Heap in practice on WAS Linux x86-64 would be approximately -Xmx76t for Java heap because the rest, or 52 TB, is used by Native heap.
*There is no Java heap size restriction from JVM, which potentially means there could be a setting as large as a 64-bit platform can address. But typically in customer memory analysis we notice about 60 percent of memory is used by Java heap and 40 percent by Native heap (including JNI). Now if we extrapolate this information for the Linux-AMD64 platform and apply it towards the user space size of 128 TB, then we could have a Java heap size of around 76 TB and 52 TB for the native heap (assuming this is only process in the Linux-AMD64 system).
When Compressed References are Enabled for 32 bit pointers (-Xcompressedrefs), as-is by Default for performance reasons, the Maximum Heap values will be much lower in gigabytes.
Maximum Heap can be set to -Xmx57g with -Xcompressedrefs in place and at later Java Versions such as Java 8 SR3 onward.
In earlier Java versions and when usin
More effective heap usage using compressed references in Java 8
*Compressed References previously only supported Java heaps up to 25 GB, but more recent versions of IBM Java 8 SR3 onward support compressed references of Java heap sizes up to 57 GB.
If Compressed References are Disabled (-Xn
*While we are specifically taking about Java Heap, it is important to mention that the WebSphere process PID itself or memory footprint will usually be larger than the Maximum Heap -Xmx value, typically by a factor of (25-35)% on busy Application Servers in Production. The process not only includes the Java Heap itself, but also underlying JNI code and data, JIT code and cache, GC infrastructure, JVM code, Clas
*Regarding 32 bit WebSphere and Java, we typically recommended Maximum Heap be set in the range of 1024M - 1536M to avoid Native Memory contention. This contention is mostly driven by Windows and its default 2GB user space/2GB kernel split, and some shared libraries sitting right at the 2GB mark. IBM Java introduced the splitHeap option exactly for this reason, and there was always the /3GB kernel option to only give 1GB to the kernel. Due to the complexity, we still generally make conservative recommendations, even though it is possible to have heaps ranging from (2-3) GB with minor modifications, depending up on the OS or platform.