|
In addition to these release notes, the following documentation is also available:
Below are some additional documentation notes.
Excluding methods from being compiled (PA-RISC and Integrity (Itanium))
To prevent the HotSpot runtime compiler from compiling certain methods, you can create a file called .hotspot_compiler and add the method to be excluded to the file.
For example, if you want to exclude java/lang/String.indexOf() from being compiled, you would add the following line to the .hotspot_compiler file:
exclude java/lang/String indexOf
By default, the HotSpot VM looks for .hotspot_compiler under the directory where libjvm.sl (libjvm.so on Itanium and PA 64-bit) resides. In addition, it looks for a .hotspot_compiler file in the current directory where the JVM was started.
For example, if you are running the JVM on a PA2.0 server, narrow mode, and the JVM was started from a script called run.sh in the directory /app/myapp/bin, it looks first in the directory {JAVA_HOME}/jre/lib/PA_RISC2.0/server and then it looks for a .hotspot_compiler file in the /app/myapp/bin directory.
Another way to exclude a method is to specify the .hotspot_compiler file using the VM option
-XX:CompileCommandFile=<list of .hotspot_compiler files separated by ":">
| For example: |
|
-XX:CompileCommandFile=/tmp/foo/.hotspot_compiler_app_version_71: \
/tmp/foo2/hc81
|
If you specify the -XX:CompileCommandFile option, it overrides the default behavior of the VM and the VM will NOT scan either the libjvm.sl (or libjvm.so for Itanium) directory or the current directory for a .hotspot_compiler file.
Support for C++ -AA and -AP options (PA-RISC only)
On HP-UX 11.0 or 11.11 PA-RISC, if you are using the ANSI C++ standard (-AA) option in an application that loads Java, you need to complete the following steps.
NOTE: On Itanium systems these steps are NOT necessary, since the C++ runtime libraries are designed to support -AA by default.
-
Run your application with the SHLIB_PATH environment variable set as follows:
$ SHLIB_PATH=/opt/java1.3/jre/lib/<ARCH>/CXX
where <ARCH> is PA_RISC or PA_RISC2.0, depending on the architecture of the application that loads Java.
$ export SHLIB_PATH
-
Now run the application that was compiled with -AA. The application and Java will both load the ANSI C++ Runtime.
Supported tools and options
To run a tool on HP-UX, either use the full path name or add the path to the startup file. For example, for javac, on the command line you could enter: /opt/java1.3/bin/javac yourfile.java. You could alternatively add /opt/java1.3/bin to your PATH statement and on the command line enter:
javac yourfile.java
The HotSpot technology accepts all of the standard tools and options. For standard tools and options documentation, refer to http://java.sun.com/j2se/1.3/docs/
Additional HotSpot option information
The HotSpot technology accepts all of the standard options as well as the following partial list of non-standard -X options.
Nonstandard options are subject to change in future releases and are prefaced with -X or -XX. For a list of non-standard options supported by HP, use the command: java -X.
-pa
Launches the PA driver and uses the PA2.0 libraries while executing on an IPF system.
-verbosegc or -verbose:gc
Prints out the result of a garbage collection to the stdout stream. At every garbage collection, the following 5 fields are printed:
[%T %B->%A(%C), %D]
%T is "GC:" when the garbage collection is a scavenge, and "Full GC:" when its a full garbage collection. A scavenge collects live objects from the New Generation only, whereas a full garmillisecondstion collects objects from all spaces in the Java heap.
%B is the size of Java heap used before garbage collection, in KB.
%A is the size after garbage collection, in KB.
%C is the current capacity of the entire Java heap, in KB.
%D is the duration of the collection in miliseconds.
-X
Prints out a brief usage message describing the non-standard options.
-Xbatch
Disables background compilation. If compilation of a large method is taking a long time, the performance engine will revert to interpreting the method. It will compile the method as a background task, running the method in interpreter mode until the background compilation is finished. The -Xbatch flag disables background compilation so that compilation of all methods proceeds as a foreground task until completed, regardless of how long the compilation takes. This flag is provided for users who desire more deterministic behavior of method compilation for purposes such as benchmarking.
-Xbootclasspath:<bootclasspath>
Specify a colon-separated list of directories, JAR archives, and ZIP archives to search for boot class files. The specified boot class libraries will be used instead of the boot class files in the jre/lib/rt.jar archive normally used by the Java 2 software.
-Xincgc
Enable the incremental garbage collector. The incremental garbage collector, which is off by default, will eliminate occasional garbage-collection pauses during program execution. However, it can lead to a roughly 10% decrease in overall performance.
-Xint
Operate in interpreted-only mode. Compilation to native code is disabled, and all bytecodes are executed by the interpreter. The performance benefits offered by the Java HotSpot adaptive compiler will not be present in this mode.
-Xmn
Set the Java new generation heap size (for example: -Xmn64m). The "new generation" is the first generation in HotSpot's generational garbage collector. This option replaces the option
-XX:NewSize=N.
-Xms<size>
Specify the initial size, in bytes, of the memory allocation pool. This 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. The default value is 5248KB.
| Examples: |
|
-Xms4194304
-Xms4096k
-Xms4m
|
-Xmx
Specify the maximum size, in bytes, of the memory allocation pool. This 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. The default value is 64MB.
| Examples: |
|
-Xmx83886080
-Xmx81920k
-Xmx80m
|
-Xnoclassgc
Disables class garbage collection.
-Xoptgc
The optimistic garbage collection flag. Improves garbage collection performance of applications with mostly short-lived objects. A server-side application that creates many short-lived objects for each transaction is likely to benefit greatly with Xoptgc. However this flag should be used with caution. It is not recommended for applications that build up objects quickly during the run time that are not short-lived.
-Xprof
(Excerpt below from Sun Microsystems' documentation.)
Profiles the running program, and sends profiling data to standard output.
-Xrs (beginning with SDK 1.3.1)
Reduces use of operating-system signals by the Java virtual machine (JVM), allowing for orderly shutdown of a Java application. Allows user cleanup code (such as closing database connections) to run at shutdown, even if the JVM terminates abruptly. For more information, see Javasoft's documentation at http://java.sun.com/j2se/1.3/docs/tooldocs/solaris/java.html.
-Xss<size>
Specifies the size of stack for each new Java thread. The default Java thread stack size is 512KB. This flag is appropriate for programs that have small thread stack size requirements and/or create several thousand threads, potentially running out of virtual memory. Program threads that overflow the allocated stack will receive java.lang.StackOverFlowException.
| Defaults: |
|
-Xss512k (Java 1.3 and 1.4 32-bit mode)
-X1m (Java 1.4 64-bit mode)
|
-Xusealtsigs (beginning with SDK 1.3.1.17, 1.4.1 and 1.4.2)
Replaces the -XX:+UseSIGUSR2 option. Instructs the JVM to avoid using SIGUSR1 and SIGUSR2 for internal operations (like Thread.interrupt() calls). In SDK 1.3.1 and
later, by default the JVM uses SIGUSR1. If -Xusealtsigs is used, then two signals halfway between SIGRTMIN and SIGRTMAX will be chosen instead.
-XX:+AggressiveHeap
This option instructs the JVM to push memory use to the limit: the overall heap is around 3850MB, the memory management policy defers collection as long as possible, and (beginning with J2SE 1.3.1.05) some GC activity is done in parallel. Because this option sets heap size, do not use the -Xms or -Xmx options in conjunction with -XX:+AggressiveHeap. Doing so will cause the options to override each other's settings for heap size.
Because the -XX:+AggressiveHeap option has specific system requirements for correct operation and may require privileged access to system configuration parameters, it should be used with caution. We have found it to be useful for certain applications that create a lot of short lived objects.
-XX:+AllowUserSignalHandlers
Instructs the HotSpot JVM option not to complain if the native code libraries install signal handlers. This only matters if the handlers were installed when the VM is booting.
|
-XX:CompileCommandFile=<list of .hotspot_compiler files separated by ":">
|
|
Specifies one or more .hotspot_compiler files that you do not want to be compiled by the JVM. Specifying this option overrides the default behavior of the JVM which is to scan the libjvm.sl directory or the current directory for a .hotspot_compiler file.
|
| Example: |
|
-XX:CompileCommandFile=/tmp/foo/.hotspot_compiler_app_version_71: \
/tmp/foo2/hc81
|
-XX:+DisableExplicitGC
Disable calls to System.gc(). The JVM still performs garbage collection when necessary.
-XX:MaxNewSize=<size> (not supported on 1.3)
Sets the default size of new generation (in bytes). The integer argument specifies bytes. The arguments can now be followed by either 'k' or 'm' to specify Kbytes or Mbytes.
-XX:NewSize=<size>
Not supported in SDK 1.3.1.x.
-XX:NewSizeThreadIncrease=<sizeInKb>
Sets the additional size added to desired new generation size per non-daemon thread (in bytes). The arguments can be followed by either 'k' or 'm' to specify KB or MB.
-XX:MaxPermSize
Sets the maximum size of permanent generation (in bytes). Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. For example, -XX:MaxPermSize=32m specifies a value of 32Mbytes for MaxPermSize. The default is 64MB.
-XX:SurvivorRatio=<size>
Ratio of eden/survivor space size. Default for SDK 1.4 is 8. If your new generation heap is 100MB, the space reserved for objects to survive a GC is ½*(100MB/8), or 6.25MB. Raising this value may improve overall application when the New space is large and/or when your application keeps a very low percentage of objects.
-XX:+UseCompilerSafepoints (PA-RISC 1.3.1, 1.4 and later, Itanium 1.4.2 and later)
Enables compiler safe points (CSP). In this release, compiler safe points is off by default. For HP-UX 11.0 and 11i, CSP requires a patch. See "HotSpot Compiler Safe Points" in these release notes.
-XX:+UseGetTimeOfDay (HotSpot 1.3.1 and later)
Instructs the JVM to use the GetTimeOfDay call instead of using the new lightweight mechanism where the number of CPU ticks since the application started is used to calculate the current time. See "Date/Time Methods - New Defaults" in these release notes for more information.
-XX:+UseOnStackReplacement (PA-RISC 1.3.1, 1.4 and later, Itanium 1.4.2 and later)
Enables on stack replacement (OSR). In this release, OSR is off by default. OSR enables the interpreter to go into compiled code while it is executing the same instance of the method call. If you enable on stack replacement, you should also enable compiler safe points
(see -XX:+UseCompilerSafepoints).
-XX:+UseSIGUSR2 (PA-RISC only)
Beginning in 1.3.1.17, replaced by -Xusealtsigs.
HP specific options and features
Additional HP specific documentation is provided in the Programmer's Guide for Java™ 2.
Noteworthy HP specific options and features from previous 1.3 releases include the following:
These are described below.
-pa option
If you have downloaded both the IPF and PA SDK on an IPF system, you can run the PA SDK by specifying this option. Normally, Java detects that you are executing on an IPF system and launches the IPF driver. To launch the PA driver and use the PA2.0 libraries, use this option.
-pa11 option (PA-RISC only)
HP's PA-RISC 2.0 architecture offers performance features not compatible with previous architectures. PA1.1 binaries can be run on a PA1.1 as well as PA2.0 based systems; however, a PA2.0 binary can only run on a PA2.0 based system. Starting with the 1.2.2 release of the SDK, HP includes two versions of the shared libraries comprising APIs and VMs. The PA2.0 shared libraries will be default if the user is running on a PA2.0 system.
You can override the use of the PA2.0 version of the shared libraries on a PA2.0 by specifying the -pa11 flag.
| For example: |
|
java -pa11 -version
|
The version string will indicate that the PA1.1 version of the VM will be used even though you are running on a PA2.0 system.
Note: If you run HotSpot with the -pa11 flag or run on a PA 1.1 system, your heap address space will be restricted to 1G.
-Xeprof option
The -Xeprof option generates profile data for HPjmeter. The -Xeprof option enables profiling of Java applications running on HotSpot version 1.2.2.05 or greater and collects method clock and CPU times, method call count, and call graph. (For more information on HPjmeter, see HPjmeter Downloads and Documentation.)
To profile your application use the following command:
java -Xeprof:<options> ApplicationClassName
To profile your applet, use:
appletviewer -J-Xeprof:<options> URL
where <options>] is a list of <key>[=<value>] arguments separated by commas.
After the profiled applet or application normally terminates execution, the Java Virtual Machine writes the profile data to a file in the current directory.
We have found the following options useful in most cases:
For CPU time metrics with minimal intrusion:
-Xeprof
or
-Xeprof:ie=no
Exact call count information and object creation profiling:
-Xint -Xeprof:ie=no
To see the complete list of available options, use
java -Xeprof:help
Supported -Xeprof options are shown below.
For detailed explanations of each option, refer to -Xeprof Options
times=quick|thorough
time_on=<integer> (SDK 1.4.1 and later)
time_on=sigusr1|sigusr2 (SDK 1.4.1 and later)
time_slice=<integer> (SDK 1.4.0 and later)
time_slice=sigusr1|sigusr2 (SDK 1.4.0 and later)
file=<filename>
inlining=disable|enable
ie=yes|no
-Xnocatch
Disables the Java "catch-all" signal handler. Use this option to generate clean stack traces from native code.
-Xoptgc
The Xoptgc, or 'optimistic garbage collection' flag, improves garbage collection performance of applications with mostly short-lived objects. A server-side application that creates many short-lived objects for each transaction is likely to benefit greatly with Xoptgc. However this flag should be used with caution. It is not recommended for applications that build
up objects quickly during the run time that are not short-lived.
-Xprep
The -Xprep option is used to dynamically preprocess (modify) bytecodes of the classes loaded by the VM. Its syntax is:
-Xprep <factory_class_name>:<arguments>
where <factory_class_name> is a qualified name of the class that will be used to create the preprocessor, and <arguments> is any string that will be passed to the method creating the preprocessor. The location of the factory class must be specified in the -Xbootclasspath option passed to the VM, together with the location of the appropriate rt.jar.
When the -Xprep option is specified, before loading the application classes, the Java VM will load the specified factory class and execute the method in the class declared as:
class <factory_class_name> implements Preprocessor {
public static Preprocessor createPreprocessor (String arg)
where Preprocessor is an interface defined as:
package hp.javatools.bytecode;
public interface Preprocessor {
public abstract byte[] instrument (String name, byte[] klass); }
The VM will pass the <arguments> specified in the -Xprep option to the createPreprocessor method as its only argument. The Preprocessor object returned by the invocation will be saved by the VM.
For each subsequently loaded class, the VM will invoke the instrument() method on the Preprocessor object, passing the name of the class being loaded, and the bytecode representation of the class. The returned array of bytes will be used by the VM as the replacement of the original version of the class. If null is returned, the original version of the class will be used.
-XX:+ServerApp
-XX:+ServerApp is a set of XX options which, when bundled together, make some applications run faster. For each release, the options as well as the values may be different depending upon the default values of XX options. We recommend that you test to see whether this set enhances the performance of your application before you use the option in production.
-Xverbosegc<options>
We recommend HP's tool HPjtune, which graphically displays information contained in an Xverbosegc log. HPjtune is available free from HP-UX Java™ Archived Releases – Release Notes.
The -Xverbosegc option prints out detailed information about the spaces within the Java Heap before and after garbage collection.
The syntax of the option is:
-Xverbosegc[:help]|[0|1][:file=[stdout|stderr|<filename>]]
:help prints this message.
0|1 controls the printing of heap information:
0 Print only after each full GC
1 (default) Print after every Scavenge and Full GC
:file=[stdout|stderr|<filename>] specifies output file
stderr (default) directs output to standard error stream
stdout directs output to standard output stream
<filename> file to which the output will be written
At every garbage collection, the following 18 fields are printed:
<GC: %1 %2 %3 %4 %5 %6 %7 %8 %9 %10 %11 %12 %13 %14 %15 %16 %17 %18 >
For a detailed explanation of the fields in the -Xverbosegc:help output, see:
HP-UX Java™ -Xverbosegc:help for Java™ 1.2 and 1.3.
Expanding heap size in native applications HP-UX 11.0 & 11.11 (11i v1) PA-RISC
If you embed libjvm in a native application, and wish to use a large Java heap, you need to ensure that enough private data space is enabled. On HP-UX 11.0 and 11.11, by using
HP-UX's EXEC_MAGIC linked with "-N" you can expand your available memory space from 1GB to around 1.7GB.
HP-UX 11.0 PA-RISC
With the installation of the required patches shown below (or the patches that supersede them), you can get larger Java heap by using the command below.
Required Patches: PHKL_27282, PHKL_23409, PHKL_28766, PHKL_29080
HP-UX 11.11 (11i v1) PA-RISC
With the installation of the required patch shown below, you can get larger Java heap by using the commands below.
Required Patch: PHKL_28428 (or its superseded patch)
See also "Application Dependent Considerations When Using Large Heap Size" in these release notes.
Expanding heap size (HP-UX 11i PA-RISC)
Hotspot 1.3.1 now supports heaps up to 3.0GB on HP-UX 11i, with the installation of the patch shown below.
For Java invoked from the command line on HP-UX 11i, Java will automatically choose an appropriate executable.
Required patch: PHKL_27278 (or its superseded patch)
-
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'.
You do not need to directly invoke these programs. 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.
See also the next section, "Application Dependent Considerations When Using Large Heap Size."
Application dependent considerations when using large heap size
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 some other part 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, and have 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 other things.
Since 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.
Using WDB to examine backtraces in Java thread stacks
You can now use HP's debugger WDB 3.0.01 (the Gnu Debugger gdb) to examine backtraces containing mixed language frames (Java and C/C++) in Java thread stacks. This will simplify debugging the VM and Java mixed-language applications. Set the environment variable GDB_JAVA_UNWINDLIB to the pathname of the Java Unwind Share Library libjunwind.sl (PA) or libjunwind.so (IA), which is in the SDK.
The default location of the Java Unwind Library in the SDK is:
/opt/java1.3/jre/lib/PA_RISC/server/libjunwind.sl
/opt/java1.3/jre/lib/PA_RISC2.0/server/libjunwind.sl
/opt/java1.3/jre/lib/PA_RISC2.0W/server/libjunwind.sl
/opt/java1.3/jre/lib/IA64N/server/libjunwind.so
/opt/java1.3/jre/lib/IA64W/server/libjunwind.so
Here are a few examples. In ksh, you would set the environment variable like this:
For 64-bit PA2.0 machines:
export GDB_JAVA_UNWINDLIB=/opt/java1.3/jre/lib/ \
PA_RISC2.0W/server/libjunwind.sl
For 64-bit Itanium 2 machines:
export GDB_JAVA_UNWINDLIB=/opt/java1.3/jre/lib/ \
IA64W/server/libjunwind.so
If you installed the SDK in a location other than the default, you would substitute the non-default location for "/opt/java1.3" in the above commands. Then use WDB as usual to debug your Java applications or core files. See the tutorial slides on Debugging Native Code with gdb (WDB) (PDF, 245KB) for help on how to use the new Java stack unwind functionality.
Asian TrueType fonts and Asian locales
The SDK now supports HP-UX Asian TrueType fonts, with the installation of patches.
For information on which HP-UX patches you need for each language
and for additional documentation on fonts, please see the
document HP-UX Fonts and the Java™ Runtime Environment.
The following Asian Locales are now supported by HP's 1.3.1.17 SDK with TrueType fonts.
| ja_JP.SJIS |
|
Japanese with Shift-JIS encoding |
|
| ja_JP.eucJP |
|
Japanese with JIS EUC encoding |
|
| ko_KR.eucKR |
|
Korean with KSC5601 EUC encoding |
|
| zh_CN.gb18030 |
|
Simplified Chinese with GB18030 encoding (supported only on HP-UX 11i) |
|
| zh_CN.hp15CN |
|
Simplified Chinese, with GB2312 EUC encoding |
|
| zh_TW.big |
|
Traditional Taiwan Chinese with Big5 encoding |
|
| zh_TW.eucTW |
|
Traditional Taiwan Chinese with CNS11643 encoding (planes 1-3) |
|
| zh_HK.hkbig5 |
|
Traditional HongKong Chinese with Big5 HK encoding |
In HP-UX Fonts and the Java™ Runtime Environment you will find information on the following topics:
Date/Time methods - New defaults
There has been a change in the way the HotSpot JVM uses the gettimeofday() system call to obtain date and time information.
For performance reasons a new mechanism is now used that uses the number of cpu ticks since the application started to calculate the current time.
As a result, changes to the system date or time using date(1), adjtime(2) or time synchronization utilities such as ntp will not be reflected in the date and time that Java returns, until the process is restarted.
If your application requires that Java immediately reflect such system time changes, you can use the -XX:+UseGetTimeOfDay option to tell the JVM to use the gettimeofday call instead of the new, lightweight mechanism. However you may notice a drop in performance.
On stack replacement
On Stack Replacement is off by default.
To enable this option, use -XX:+UseOnStackReplacement.
If the VM is executing a method that has a loop with a large number of iterations, an intra-method hotspot will occur. In order to get better performance, the method should run in compiled mode instead of interpreted mode. On stack replacement enables the interpreter to go into compiled compiler safe safe point it is executing the same instance of the method call. If you use on stack replacement, you should also enable compiler safe points (see the next section).
HotSpot compiler safe points
Compiler Safe Points is off by default. To enable it, use the -XX:+UseCompilerSafepoints option.
Enabling compiler safe points guarantees a more deterministic delay to stop all running java threads before doing a safepoint operation, namely garbage collection and deoptimization.
NOTE: For both HP-UX 11.0 and 11i, using Compiler Safe Points requires a patch. The required patch numbers are shown below. For information on locating and installing patches, go to Patch Information.
| HP-UX 11.0 |
|
PHKL_27770 (or its superseded patch) |
|
| HP-UX 11i |
|
PHKL_24751 (or its superseded patch) |
Profiling capability
In the SDK version 1.3.1.05 and later, a SIGPROF handler to support future profiling capability is installed automatically. This may cause incompatibilities with other native code or profiling tools which use SIGPROF.
You can turn off the SIGPROF handler by using the following option:
-XX:+ReduceSignalUsage
However you should be aware that using this option also turns off the SIGQUIT handler. Therefore you will not be able to get a Java stack trace.
Using JNI - Main/Primordial thread stack size limits
The primordial thread is the first thread when a process is created. This is the thread that has the main method. It is also called the main thread. The primordial thread stack size is controlled by the kernel parameter maxssiz or maxssiz_64bit. The Java VM (JVM) has two options for controlling the stack size:
-XX:MainThreadStackSize=n
-Xss[n][k or m]
In the Java VM the size of the primordial thread is restricted to the *greater* of MainThreadStackSize (default 2M) or ThreadStackSize (specified by -Xss). For example, if you specify -Xss1m, the JVM still takes 2M for the main thread. And if you specify -Xss4m, the JVM takes 4M for the main thread as well.
If your application calls JNI_CreateJavaVM or JNI_AttachCurrentThread from the primordial thread, under certain conditions the stack usage could cross the JVM-imposed primordial thread stack size limit of 2M and cause a stack overflow situation in the native code itself, even if no Java code was ever run on the primordial thread.
One workaround is to use the option -XX:MainThreadStackSize=<value> to increase the primordial thread stack size, However be aware that -XX options are non-standard options, and are liable to change from release to release.
Other workarounds and examples are provided in our Programmer's Guide along with the effects of using maxssiz on the amount of writeable data space available to the application. Refer to the JNI chapter of our Programmer's Guide for Java 2 at: Using Java™ 2 JNI on HP-UX
Using JNI - Non-Main/Primordial thread stack size limits
The default stack size for 1.4 64-bit mode JVM - created threads 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, you will want to adjust the stack size to avoid overflows.
Here are some suggestions to work around stack overflow problems in threads other than the main thread:
-
If the thread is created in native code and is attached to Java through JNI_AttachCurrentThread, increase the stack size attribute when creating the thread with pthread_create.
-
If the thread is created inside Java and there is a stack overflow condition, increase the thread stack size with -Xss<n>
Using JNI - Dereferencing null pointers
In Java 2, JNI code that incorrectly dereferences NULL will result in a SIGSEGV, which may be different behavior than that experienced with Java 1.1 releases. For example, in Java 1.1, JNI methods that dereference NULL pointers like this:
int *p = NULL;
return *p;
will return the value 0.
With the Java 2 the HotSpot VM, such dereferences result in a SIGSEGV, and java NULL checks can be performed without having to emit explicit code to do so. With Java 2 HotSpot, the signal is caught, and a null pointer exception is thrown if the offending instruction was within the VM (compiled code, or in the interpreter). This method may uncover hidden programming errors.
Also, if you are including the HP-UX Runtime Environment for the Java 2 Platform in an application and bypassing our standard driver, for example by making calls to JNI_CreatJavaVM from inside the application, link the application with the "-z" option. The -z option will indicate that dereferencing NULL pointers in the application should generate a SIGSEGV
instead of the traditional behavior of returning zero. If you do not, you will not be able to take advantage of implicit null pointer checks; null pointer checks will have to be explicit, potentially degrading performance. Linking with -z may also expose existing but quiet bugs in an application. This is because the SIGSEGVs were not being generated before.
Using JPDA
The JPDA architecture and components are documented at
http://java.sun.com/products/jpda/ and http://java.sun.com/reference/docs/index.html. HP's SDK version 1.3.0.01 supports both the HotSpot and Classic VMs. The jdb for HP-UX is similar to the Solaris implementation. For usage information, see "Sun VM Invocation Options" at http://java.sun.com/products/jpda/doc/conninv.html.
Launching the Java application VM manually when debugging
(excerpted from http://java.sun.com/products/jpda/readme.html)
If you are running the version of jdb provided in this release, the application VM is launched for you with the debugger back end loaded. However, in the following cases, you will be launching your own application VM, either by hand or in your implementation.
-
Remote debugging with the -attach or -listen jdb option.
-
You are implementing a debugger which uses the JDWP directly.
-
You are implementing a debugger back end which uses JVMDI.
Currently, the first two cases require a command line like the following:
java -Xdebug -Xnoagent -Djava.compiler=NONE
-Xrunjdwp:transport=dt_socket,server=y,suspend=y
-classpath class-path class-name
The -Xdebug option enables debugging. The -Xnoagent disables the default sun.tools.debug debug Agent. The -Djava.compiler=NONE disables the JIT compiler.
For the third case, you must use the same command line options as described above, but you are free to use your own mechanism for loading the JVMDI client into the application VM. You do not need to use -Xrun.
The Connection and Invocation Details document at http://java.sun.com/products/jpda/doc/conninv.html contains more information on necessary VM invocation options and sub-options of -Xrunjdwp.
Closing a Socket When Accept or Read is Pending on Same Socket (PA-RISC & HP Integrity)
Because of changes to the mechanism by which a socket is closed in the VM, in 1.3.1.17 you no longer need to use the -XdoCloseWithReadPending option we recommended in earlier releases, and patches are not required for either PA-RISC or HP Integrity.
HP-UX 11.00 - PHNE_26771 (or the patch that supersedes it)
Compiling with C++ libraries
Libraries compiled with the cfront HP C++ compiler will not work with HotSpot. HotSpot requires use of the HP aCC compiler for any application C++ libraries loaded dynamically at runtime.
CLASSPATH
CLASSPATH will be automatically set during installation. If you get the error "Unable to initialize threads: cannot find class java1.3/lang/Thread", your CLASSPATH environment variable may be incorrect.
See also http://java.sun.com/reference/docs/index.html.
Compatibility between release 1.3 and previous releases
Compatibility information is provided at: http://java.sun.com/j2se/1.3/compatibility.html.
Web sites with more information
The following websites have additional information:
Java Standard Edition Platform documentation:
http://java.sun.com/docs.
Java 2 SDK version 1.3 Features and Tools:
http://java.sun.com/reference/docs/index.html.
Java 2 SDK version 1.2 Features and Tools:
http://java.sun.com/products/jdk/1.2/docs/index.html.
Java 2 version 1.3 API specification:
http://java.sun.com/j2se/1.3/docs/api/index.html.
Java 2 platforms and APIs - Authorized Books:
http://java.sun.com/docs/books/index.html.
Java tutorial:
http://java.sun.com/docs/books/tutorial/index.html.
Java security:
http://java.sun.com/security/index.html.
Java products and APIs
http://java.sun.com/products/.
http://java.sun.com/j2se/.
Swing connection newsletter:
http://java.sun.com/products/jfc/tsc/index.html.
Performance tuning Java on HP-UX:
HP-UX performance tuning Java™ (techniques, tools, and tips).
|
