Automatic LDR_CNTRL=MAXDATA values (32-bit only)
The automatic setting of the LDR_CNTRL=MAXDATA environment variable value is linked to the size of the Java™ heap used by the SDK. To simplify the setting of LDR_CNTRL=MAXDATA, the SDK sets an appropriate value that is based on the maximum size of the heap.
- If the heap size is greater than 3 GB, LDR_CNTRL=MAXDATA=0@DSA is set.
- If the heap size is greater than 2.25 GB but no more than 3 GB, LDR_CNTRL=MAXDATA=0XB0000000@DSA is set.
- Otherwise, LDR_CNTRL=MAXDATA=0XA0000000@DSA is set.
Segment | Contents |
---|---|
0 | AIX® kernel |
1 | Java program |
2 | Primordial Stack (main program thread stack) |
3 | Native Heap (malloc'ed space) |
4-C | Native Heap (malloc'ed space) or Memory Mapped space (mmap/shmat) |
D | Shared library code |
E | Memory Mapped space (mmap/shmat) |
F | Shared library data |
Segments 0 and 1 have a fixed usage; segment 0 is always used for the AIX kernel and segment 1 is always used for the application program code. In this case, the application program code is generally the java executable.
- Segment 2 is used for the stack of the application program.
- Segment 3 to segment C are available to the native heap, although initially only segment 3 is reserved for the native heap. Because the JVM and JIT allocate space from the native heap, it can expand to consume additional contiguous segments.
- The Java heap is allocated in contiguous space in segment E, or from segment C and lower segments. That is, a Java heap of 256 MB or smaller uses just segment E. A Java heap of more than 256 MB uses segments C, B, ... as necessary, up to a maximum size of 2.25 GB using all of C-4. At the maximum size of 2.25 GB, the native heap cannot expand further than segment 3.
- Segment D has been allocated by the operating system for shared library code, segment F is used for shared library data. The JVM and JIT are mostly contained in shared libraries which are loaded into these segments.
It is clear from this memory layout that some Java applications can have problems when using large Java heaps. If a Java heap of 2.25 GB is used, the native heap is restricted to a single 256 MB segment. If the Java application created many threads, for example, it might consume a large fraction of the native heap for thread stacks, which can make the JVM or JIT run out of native heap space. Such a situation requires more careful consideration of what size of Java heap should be used, and might motivate the use of an explicit MAXDATA setting.
For a Java heap larger than 2.25 GB, a different MAXDATA setting is needed to free up additional segments for a contiguous area large enough for the heap. With the MAXDATA=0xB0000000@DSA automatic setting, the memory layout changes to:
Segment | Contents |
---|---|
0 | AIX Kernel |
1 | Java program |
2 | Primordial stack (main program thread stack) |
3 | Native Heap (malloc'ed space) |
4-D | Native Heap (malloc'ed space) or Memory Mapped space (mmap/shmat) |
E-F | Memory Mapped space (mmap/shmat) |
- Segment 2 is used for the stack of the application program.
- Segment 3 to segment D are available to the native heap, although initially only segment 3 is reserved for the native heap. Because the JVM and JIT allocate space from the native heap, it can expand to consume additional contiguous segments. Shared libraries must also be privately loaded into this range of segments because segments D and F are not reserved for shared libraries.
- The Java heap is allocated in contiguous space from segment F and lower segments, up to a maximum size of 3 GB using all of F-4.
For a Java heap larger than 3 GB, the only option is to use MAXDATA=0@DSA, resulting in a memory layout as follows:
Segment | Contents |
---|---|
0 | AIX kernel |
1 | Java program |
2 | Native Heap (malloc'ed space) and Primordial Stack (main invocation stack) |
3-F | Memory Mapped space (mmap/shmat) |
The Java heap in this case consumes all of segments 3 through F, for a maximum size of 3.25 GB. The primordial stack, native heap, and shared libraries are all packed into segment 2. It is unlikely that many Java applications could successfully run in this configuration.