Determine your requirements It's important to understand the real requirements of your application. We recommend that you perform sizing tests before deployment with a realistic load, while monitoring with -Xverbosegc and a tool like GlancePlus. Learn more about GlancePlus and the -Xverbosegc option. Our Java™ Performance Tuning website has much valuable information on profiling and performance tools. In addition, HP-UX patches may be needed for expanding memory size. Read the release notes for your SDK release to determine if you need a HP-UX patch. Memory layout under HP-UX 11.0 (PA-RISC only) In the HP-UX 32-bit process memory layout, there are four "spaces" used in the runtime: ---------- 0x00000000
| text |
---------- 0x40000000
| data |
---------- 0x80000000
| sh mem |
---------- 0xc0000000
| sh mem |
---------- 0xffffffff Application "text," the code in the executable, goes in text space. Shared libraries get mapped into the shared memory, usually above 0xc0000000 but if there are many shared libraries or a lot of shared memory in use they will creep down into the 0x80000000-0xbfffffff range. So in a normal executable, writable data is in the range 0x40000000 to 0x7fffffff. C heap starts in the 0x4-------'s, and mmap-ed areas start in the 0x7's and work back down. Thread stacks also start in the 0x7's, and get allocated at lower and lower addresses as more threads get allocated. Almost all of the native code for the JDK is in shared libraries. There is just a very small amount of code in the launcher down in text space. We take advantage of otherwise unused space in text space by linking with EXEC_MAGIC. With EXEC_MAGIC, on HP-UX 11.0, our memory layout looks like this. ---------- 0x00000000
| text |
---------- the java launcher uses memory up to about 0x00008000;
it is writeable under EXEC_MAGIC.
| data |
---------- 0x80000000
| sh mem |
---------- 0xc0000000
| sh mem |
---------- 0xffffffff The PA1.1 binary is not EXEC_MAGIC because the jit in Classic is not compatible with EXEC_MAGIC. The PA2.0 launcher binary is EXEC_MAGIC. With EXEC_MAGIC, we have all the space from around 0x00008000until 0x80000000 as writeable data area. Now the C heap will start way down there. This allows us to allocate a Java™ heap larger than 1GB. However, you should be aware of certain considerations which might be application dependent. These are described in Application dependent considerations when using large heap size HP-UX 11i PA-RISC. Additional memory available under HP-UX 11i (PA-RISC only) With HP-UX 11i, Java™ supports a Java™ heap as large as 3.8GB. Space previously reserved for shared memory can be used for process private writeable data. This should be used with caution, however, as a Java™ heap this large is subject to lengthy pauses for garbage collection. Due to the design of HP-UX, the heap is not one contiguous mmap. When the heap is getting this large, either the new space, set with -Xmn, or old space, set by the difference of Xmx and Xmn, must be 900MB or less. -------------- 0x00000000
| text |
-------------- around 0x00008000
| data |
-------------- 0x80000000
| data |
-------------- 0xc0000000
| data+shmem |
-------------- 0xffffffff When using a large Java™ heap, you should be aware of certain considerations which might be application dependent. These are described in Application dependent considerations when using large heap size HP-UX 11i PA-RISC. In addition, be aware that if you need to load extra native libraries at runtime, you need to carefully test to ensure that you haven't used up all your address space for Java™ heap so that there won't be enough shared memory left to load another shared library. Allocating physical memory and swap in the Java™ heap The Hotspot JVM uses mmap to reserve memory for the various spaces within the Java™ heaps. These memory mapped regions are created during initialization and are sized so that they can hold the maximum size of heap specified with the -Xmx command line option. Normally the HP-UX reserves swap space for the whole of these memory mapped heap regions when they are first mapped. However, in order to conserve system swap resources, the JVM, by default, maps these regions using the mmap MAP_NORESERVE flag (see man 2 mmap for details). When using this option, no swap space is reserved when the region is first created, swap will only be reserved for each page as and when it is first used. In both cases physical memory pages will only be allocated when the pages are first used. The JVM doesn't necessarily use all the space that it's reserved for the Java™ heap. On initialization it commits a portion of this memory, the size of which is controlled by the -Xms option. The size of this committed area (as shown by the capacity value in the -Xverbosegc output) can vary between this minimum value and the maximum allowable size (controlled by the -Xmx option), as the amount of retained objects in the heap increases and decreases. Starting with SDK 1.4.1.05, the way that physical memory and swap space are allocated within the Java™ heap has changed. The JVM now ensures that swap is reserved for the whole of the currently committed area of the heap by touching each memory page. It also now explicitly releases this swap if the size of the committed area decreases. (These decreases are not very common.) Prior to 1.4.1.05 the JVM did neither of these. Note that under HP-UX, when memory pages are touched, physical memory is allocated and swap is reserved as well. As a result, in some applications you may now see a larger memory footprint. When you monitor your Java™ processes with Glance or other tools, you are likely to see a higherRSS memory usage, especially on startup because the memory is being allocated earlier than before. In some cases, your application startup may be slightly slower. It is the physical memory allocation that shows up in the increased RSS values, not the swap reservation. Useful key command line options for allocating memory Below are three important command line options with regard to allocating memory, and some examples of how to use them. (For a complete list of HotSpot JVM options, refer to the Programmer's Guide chapter on HotSpot technology. -Xms<size>
Specifies the initial size of the committed memory within the Java™ heap. It also specifies the minimum size of the committed area. The value must be a multiple of 1024 greater than 1MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. For example, -Xms6291456, -Xms6144k, -Xms1500M -Xmx<size>
Specifies the maximum size of the Java™ heap. The value must a multiple of 1024 greater than 2MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. For example, -Xmx83886080, -Xmx81920k, -Xmx1500M You will notice the increased memory footprint described in the previous section most if you set -Xms to the same value as -Xmx. This is because the whole of the associated heap spaces are committed and the JVM reserves swap for them by touching every page. In this case it would be better to use the -XX:+ForceMmapReserved option because it is more efficient. -XX:+ForceMmapReserved
Tells the JVM to reserve the swap space for all large memory regions used by the JVM (Java™ heap). This effectively removes the MAP_NORESERVE flag from the mmap call used to map the Java™ heaps and ensures that swap is reserved for the full memory mapped region when it is first created. When using this option the JVM no longer needs to touch the memory pages within the committed area to reserve the swap and as a result , no physical memory is allocated until the page is actually used by the application. Examples -Xmx1500M
The initial Java™ heap memory commitment will be relatively small. This approach maximizes the availability of system swap across your application machine. In SDK 1.4.1.05, the initial JVM footprint increases by about 22Mb; in SDK 1.4.2.00, it increases by approximately 33Mb. -Xmx1500M -Xms1500M
The initial Java™ heap memory commitment will be 1500Mb. You may notice a pause during startup, even on a fast machine, as the memory pages are touched. In this case it would be better to use the -XX:+ForceMmapReserved option because it uses memory more efficiently. If your application typically uses less memory than this, setting -Xmx and -Xms to the same value does not make the most efficient use of system shared memory. You may want to use a smaller value for -Xms instead. -Xmx1500M -XX:+ForceMmapReserved
There will be no pause corresponding to initial memory commitment. 1500Mb of swap is reserved for the Java™ application. This swap cannot be shared with any other processes on the system. Application dependent considerations when using large heap size HP-UX 11i PA-RISC Thread stacks and C heap are allocated from the same address space as the Java™ heap, so if you set the Java™ heap too large, new threads may not start correctly. Or other parts of the runtime or native methods may suddenly fail if the C heap cannot allocate a new page. An application may start up correctly with a 1.7GB heap, but this does not necessarily mean it's going to work correctly. For example, if you use a 1MB stack size (-Xss1m), and there are about 80 threads in the process, you will have 80MB for stacks. If you have native libraries, you would probably add another 64MB for C heap. You have now used a total of 144MB of your heap for stacks and C heap, so this address space is not available for Java™ heap. Because all programs have varying C heap requirements and have varying numbers of threads, it's difficult to ascertain what the effect will be of running the application at its limit. It's important to understand the real requirements of your application. We recommend that you perform sizing tests before deployment with a realistic load, while monitoring with the -Xverbosegc option and a tool like GlancePlus. Expanding heap size in native applications on PA-RISC HP-UX 11.11 and later releases If you embed libjvm in a native 32-bit application and wish to use a large Java™ heap, you need to ensure that enough private data space is enabled. You can expand your available memory space from 1GB to around 1.7GB on HP-UX 11.11 and later releases by using HP-UX's EXEC_MAGIC; link your executable with "-N". On HP-UX 11.11, you may need to install HP-UX patch PHKL_35564 (or its superseded patch) to get a larger Java™ heap. Releases after 11.11 do not require any patches for this feature. Use the commands shown below to get the larger Java™ heap. Also refer to Application dependent considerations when using large heap size HP-UX 11i PA-RISC.. Expanding heap size in native applications on Integrity HP-UX 11.23 and later releases If you embed libjvm in a native 32-bit application and wish to use a large Java™ heap, you need to ensure that enough private data space is enabled. You can expand your available memory space from 1GB to around 1.7GB on HP-UX 11.23 and later releases by using HP-UX's EXEC_MAGIC; link your executable with "-N". Expanding heap size in HP-UX PA-RISC1 Hotspot supports heaps larger than 3GB on HP-UX PA-RISC. In theory, a process can have 3.8GB address space. However, the address space available as java heap is smaller than 3.8GB due to reserved address space for primordial stack, other private segment in JVM like permanent generation, code cache and interpreter, and other reserved address range and alignment. When Java™ is invoked from the command line on HP-UX PA-RISC, Hotspot automatically chooses an appropriate executable. This is how Hotspot chooses the executable for SDK 1.4.2.09 and JDK 5.0.01 and older releases: - For heaps less than 1500MB, the executable is 'java'.
- For heaps greater than or equal to 1500MB, and less than 2400MB the executable is 'java_q3p'.
- For heaps of 2400MB to 3.8GB, the executable is 'java_q4p'.
This is how Hotspot chooses the executable for SDK 1.4.2.10, JDK 5.0.02, JDK 6.0.00 and later releases: - For (heaps + max perm + stack limit) less than 1600MB, the executable is 'java'.
- For heaps (heaps + max perm + stack limit) greater than or equal to 1600MB, and less than 2500MB the executable is 'java_q3p'.
- For (heaps + max perm + stack limit) of 2500MB to 3.8GB, the executable is 'java_q4p'.
Note: For releases after SDK 1.4.2.10 and JDK 5.0.02, when using CMS, the estimated threshold for switching is about 3% less than the values above, assuming default values are used for NewSize,MaxNewSize, NewRatio, CMSMarkStackSize and CMSRevisitStackSize. (heaps mean total size of java heap determined by -Xmx option. max perm is perm generation size limit determined by -XX:MaxPermSize=... option. stack limit is primordial stack size limit which is initialized by kernel parameter maxssiz unless it is changed explicitly by rlimit(2), shell's 'ulimit -s', etc.) You do not need to invoke these programs directly. Just invoke 'java' as usual, and the appropriate program will be run for you. In addition, be aware that if you wish to use very large heaps, because of segmentation in the HP-UX virtual address space, when the Java™ heap is larger than 3000MB, either new space (-Xmn) or old space (-mx minus -Xmn) must be approximately 850MB or less. Also refer to Application dependent considerations when using large heap size HP-UX 11i PA-RISC. Expanding heap size in HP-UX Integrity2 Hotspot 1.4.2.X/5.0.X/6.0.X running in 32-bit mode supports heaps larger than 3GB on HP-UX 11.23 and later. In theory, an mpas 32-bit process on HP-UX 11.23 and later can have 4GB address space. However, the address space available as java heap is smaller than 4GB due to reserved address space for primordial stack, other private segment in JVM like permanent generation, code cache and interpreter, and other reserved address range and alignment. For Java™ invoked from the command line on HP-UX 11.23, Java™ will automatically choose an appropriate executable. This is how Hotspot chooses the executable for SDK 1.4.2.09, JDK 5.0.01 and older releases: - For heaps less than 1700MB, the executable is 'java'.
- For heaps greater than or equal to 1700MB the executable is 'java_q4p`.
This is how Hotspot chooses the executable for SDK 1.4.2.10, JDK 5.0.02, JDK 6.0.00 and later releases: - For (heaps + max perm + stack limit) less than 1800MB, the executable is 'java'.
- For (heaps + max perm + stack limit) greater than or equal to 1800MB the executable is 'java_q4p`.
Note: For releases after SDK 1.4.2.10 and JDK 5.0.02, when using CMS, the estimated threshold for switching is about 3% less than the values above, assuming default values are used for NewSize, MaxNewSize, NewRatio, CMSMarkStackSize and CMSRevisitStackSize. (heaps mean total size of java heap determined by -Xmx option. max perm is perm generation size limit determined by -XX:MaxPermSize=... option. stack limit is primordial stack size limit which is initialized by kernel parameter maxssiz unless it is changed explicitly by rlimit(2), shell's 'ulimit -s', etc.) You do not need to directly invoke these programs. Just invoke 'java' as usual, and the appropriate program will be run for you. Recent IPF JVMs have -Xmpas:on and -Xmpas:off options. If -Xmpas:on was used, java_q4p is executed regardless of the java heap size. This might be useful when your java application needs large malloc area or many number of threads. On PA-RISC system, Q3P and Q4P executables provide larger private data space. On IPF HP-UX, MPAS (Mostly Private Address Space) executable provides larger private address space. A Non-MPAS executable has about 1.9GB private address space and an MPAS executable can have close to 4GB private address space. HP JVM for IPF HP-UX with large data space support is an MPAS executable and named java_q4p. 1, 2 The numbers provided in "Expanding heap size in HP-UX PA-RISC" and "Expanding heap size in HP-UX Integrity" are approximate and might change from release to release. Java™ and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Hewlett-Packard is independent of Sun Microsystems, Inc. | 