HP-UX Programmer's Guide for Java 2
Table Of Contents
- Table of Contents
- 1 Introduction
- 2 HotSpot Technology Tools and Commands
- 3 Configuration for Java™ Support
- 4 Performance and Tuning
- 5 Measuring System Performance
- 6 Using Threads
- 7 Using Signals
- 8 Using Java™ 2 JNI on HP-UX
- 9 Expanding Memory
- Determine your requirements
- Memory layout under HP-UX 11.0 (PA-RISC only)
- Additional memory available under HP-UX 11i (PA-RISC only)
- Allocating physical memory and swap in the Java™ heap
- Useful key command-line options for allocating memory
- Application-dependent considerations using large heap size HP-UX 11i PA-RISC
- Expanding heap size in native applications on PA-RISC HP-UX 11.11 and later releases
- Expanding heap size in native applications on Integrity HP-UX 11.23 and later releases
- Expanding heap size in HP-UX PA-RISC
- Expanding heap size in HP-UX Integrity
- 10 Diagnosing Memory Leaks
- A JDK/JRE 6.0.n and 7.0.n Usage Notes
- Using Java 2 JNI on HP-UX
- Garbage collection
- Asian TrueType fonts and Asian locales
- Date/Time methods defaults
- Profiling
- Compatibility with previous releases
- Java Cryptography Extension (JCE) policy files
- Configuring the Java Runtime Plug-In
- CLASSPATH environment variable
- Java Web Start technology usage
- Upgrading from a previous Java Web Start version
- IPv6 support
- Allocation Site Statistics and Zero Preparation -Xverbosegc
- JDK 6.0.04 flags
- GC log-rotation support
- NUMA collector enhancements
- ThreadDumpPath support
- Garbage-First garbage collector (-XX:+UseG1GC)
- jmap, jinfo, and jstack tools included in JDK 6.0.03
- Additional Java Web Start documentation
- B JDK/JRE 5.0.n Usage Notes
- Using Java 2 JNI on HP-UX
- Garbage collectors: Parallel and Concurrent Mark Sweep
- Allocating physical memory and swap in the Java heap
- Asian TrueType fonts and Asian locales
- Date/Time methods defaults
- Profiling
- Closing a socket (PA-RISC only)
- Compatibility with previous releases
- Java Cryptography Extension (JCE) policy files
- Allocation Site Statistics and Zero Preparation -Xverbosegc
- IPv6 support on Java 5.0
- GC log-rotation support in 5.0
- ThreadDumpPath support in 5.0
- Dynamically loaded libraries in 5.0
- Performance improvement for String.intern()
- Configuring the Java Runtime Plug-In
- CLASSPATH environment variable
- Java Web Start technology usage
- C SDK/RTE 1.4.2.n Usage Notes
- Removing support for unwanted architectures in the JRE
- Support for dynamic thread local storage (TLS)
- Signal Chaining functionality
- Using Java 2 JNI on HP-UX
- HotSpot JVM options
- Garbage collectors: Parallel and Concurrent mark sweep
- Allocating physical memory and swap in the Java heap
- Asian TrueType fonts and Asian locales
- Date/Time methods defaults
- Profiling
- Closing a socket when accept or read is pending (PA-RISC) - new patch information!
- Compatibility with previous releases
- Runtime Plug-In usage and configuration
- GC log-rotation support
- ThreadDumpPath support
- D Additional Resources
- Index

NOTE: The default stack size for 1.4 and 5.0 64-bit mode threads created by the JVM
is 1MB. On PA-RISC 32 and 64-bit systems, the default stack size is 64KB. Therefore,
if you are using C language main programs that attach with JNI, for threads created
using the pthread library, you will want to adjust the stack size to avoid overflows.
For further details on thread stack size limits, see “Main/primordial thread stack size
limits” (page 57) and “Non-Main/Primordial thread stack size limits” (page 59).
Replacing the C++ default global allocation and deallocation functions
If your application provides its own new and delete operators, be aware that as a result
of dynamic linking, the JVM will now call your implementation of the operators instead
of the standard implementation. If you wish to override the new, new[], delete, and
delete[] operators inside your application or library but prevent other libraries, such
as the JVM, from calling your implementation, you can explicitly hide your operator
symbols by using the following options on the aCC compile line:
aCC -Bhidden=_ZdaPv,_ZdaPvRKSt9nothrow_t,_ZdlPv,_ZdlPvRKSt9nothrow_t \
-Bhidden=_Znam,_ZnamRKSt9nothrow_t,_Znwm,_ZnwmRKSt9nothrow_t ...
Input to the -Bhidden option are mangled C++ operator names; these names can be
deciphered with the c++filt command. The -Bhidden option is only available on
Integrity systems. For PA-RISC systems, the following can be added to the aCC link
line:
aCC -b -Wl,-h__nw__FUl,-h__dl__FPv ...
Java™ calling a native (non-Java) method
The first capability that JNI provides is to allow Java™ running under the Java™ Virtual
Machine (JVM) to make native method calls. This allows the Java™ programmer to
supply a native implementation instead of a Java™ implementation for any method
in any user defined class. The Java™ keyword native is used in the declaration of the
method and no body or definition is supplied in the Java™ source.
native void sample(int x, int y);
The above declares a non-static native method named "sample" which returns a void
and it accepts two integers as parameters.
The native method must be implemented in C or C++. When using C++ native methods
special care must be taken to properly initialize the C++ runtime before transferring
control to any C++ native method. For the HP C++ compiler this means that the routine
_main must be called before transferring control to any C++ method. The examples
below detail a mechanism for ensuring that the C++ runtime is properly initialized.
All Java™ native methods must reside in a shared library. This implies that the native
methods must be built using the +z or +Z compiler options. These options cause the
compiler to generate PIC (Position-Independent-Code). The shared library containing
the native method implementation is dynamically loaded during execution of the Java™
46 Using Java™ 2 JNI on HP-UX