|
In addition to these release notes, the following documentation is also available:
Below are the following additional documentation notes:
Support for dynamic thread local storage (TLS)
Dynamic thread local storage is fully supported on all HP Integrity (Itanium) systems, beginning with SDK Versions 1.4.2.00 and 5.0.
Dynamic TLS is not available on any HP-UX PA-RISC system. However there is a workaround. Refer to "shl_load HotSpot libjvm problem due to TLS (PA-RISC)" in these release notes for details.
Excluding methods from being compiled (PA-RISC and 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 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 first looks 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 ":">
| 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 directory or the current directory
for a .hotspot_compiler file.
Support for C++ applications built with -AA and -AP options (PA-RISC)
Java supports the -AA and -AP options to build your C++ product. On Itanium
systems, the C++ runtime libraries support -AA and -AP by default.
On HP-UX 11.0 or 11.11 PA-RISC, if you are using the ANSI Standard C++
runtime (-AA) option in an application that loads Java, you need to
use the -AA version of libjvm and libfontmanager. The Standard C++ Runtime version of these libraries are shown below. Note that these libraries are provided as a separate download on the same page from where you download the SDK and RTE, starting at this webpage:
SDK and RTE 1.4.2.x Downloads and Documentation
./jre/lib/PA_RISC2.0/libjvm_v2.sl
./jre/lib/PA_RISC2.0W/libjvm_v2.sl
./jre/lib/PA_RISC2.0/libfontmanager_v2.sl
./jre/lib/PA_RISC2.0W/libfontmanager_v2.sl
The native application must be linked with, or must dynamically load
these versions of the Java libraries if your C++ application is compiled
using -AA.
The Standard C++ version of the JVM libraries are supported for
PA_RISC2.0 and PA_RISC2.0W architectures only.
If the JVM is invoked through the standard Java driver, then use
the -V2 option to use the Standard C++ runtime.
For example:
java -V2 <javaprog>
Supported tools and options
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.4.2/docs/tooldocs/tools.html
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.4/bin/javac yourfile.java. You could alternatively
add /opt/java1.4/bin to your PATH statement and on the command line
enter: javac yourfile.java
IPv6 support (Internet Protocol version 6)
IPv6 (Internet Protocol version 6) is a set of Internet Protocol specifications
designed to provide enhancements over the capabilities of the existing IPv4
service in terms of scalability, security, mobility, ease-of-configuration,
and real-time traffic handling.
For more information, refer to Sun Microsystems' "Networking IPv6 User
Guide for J2SDK/JRE 1.4" at http://java.sun.com/j2se/1.4/docs/guide/net/ipv6_guide/
HP-UX 11.11 (11i v1) PA-RISC and 11.23 (11i v2) Itanium support dual
protocol stacks IPv4 and IPv6. IPv6 is not currently supported on
HP-UX 11.0 or 11.22 (11i v1.5). In this SDK release, the IPv4 protocol
stack is the default. To support IPv6, HP-UX 11.11 (11i v1) requires
patches; HP-UX 11.23 (11i v2) does not.
To turn on IPv6 support, in addition to installing patches for HP-UX
11.11, you need to set the system property as follows:
java.net.preferIPv4Stack=false
Or at the Java command line you can use the option
-Djava.net.preferIPv4Stack="false"
For the availability of patches required for IPv6 support on HP-UX 11.11, please refer to
Additional HotSpot option information
The HotSpot technology accepts all of the standard options as well as the
following partial list of non-standard -X and -XX options. Non-standard options
are not guaranteed to be supported on all VM implementations, and are
subject to change without notice in subsequent releases of the Java 2 SDK.
See also JavaSoft's "Java HotSpot VM Options" at
http://java.sun.com/docs/hotspot/VMOptions.html.
-d64
Runs Java in 64-bit mode. refer to the section 64-bit support under Known Issues in these release notes for more information on patches required.
-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 it is a full garbage collection. A scavenge collects live objects from the New Generation only, whereas a full garbage collection 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 seconds.
-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.
-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 be 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.
-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, refer to JavaSoft's documentation at: http://java.sun.com/j2se/1.3/docs/tooldocs/solaris/java.html
-Xusealtsigs (beginning with SDK 1.3.1.13, 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.4.1 and later, by default the JVM uses both SIGUSR1 and SIGUSR2. If -Xusealtsigs is used, then two signals halfway between SIGRTMIN and SIGRTMAX will be chosen instead.
-Xss<size>
Specifies the size of stack for each new Java thread. The default
Java thread stack size is 512 KB. 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)
|
-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>
Sets the maximum size of new generation (in bytes). Note that in
SDK 1.2.2 this option took an integer that specified a value in
KB. Starting with SDK 1.3.1, the integer argument specifies
bytes. The arguments can now be followed by either 'k' or 'm' to
specify KB or MB.
-XX:NewSize=<size>
Sets the default size of new generation (in bytes). Note that in HotSpot 1.0.1 this option took an integer that specified a value in Kbytes. Starting with HotSpot 1.3.1, the integer argument specifies bytes. The arguments can now be followed by either 'k' or 'm' to specify Kbytes or Mbytes.
-XX:NewSizeThreadIncrease=<sizeInKb>
Sets the additional size added to desired new generation size per
non-daemon thread (in bytes). Note that in SDK 1.2.2 this option
took an integer that specified a value in KB. Starting with HotSpot
1.3.1, the integer argument specifies bytes. The arguments can now be
followed by either 'k' or 'm' to specify KB or MB.
-XX:MaxPermSize=<size>
Sets the maximum size of permanent generation (in bytes). Note that in
SDK 1.2.2 this option took an integer that specified a value in
KB. Starting with SDK 1.3.1, the integer argument specifies
bytes. The arguments can now be followed by either 'k' or 'm' to
specify KB or MB.
-XX:PermSize=<size>
Specifies the initial size, in bytes, of the Permanent
Space memory allocation pool. This value must be a
multiple of 1024 greater than 1 MB. Append the letter k
or K to indicate kilobytes, or m or M to indicate
megabytes.
| Examples: |
|
-XX:PermSize=6291456
-XX:PermSize=6144k
-XX:PermSize=6m |
|
| Default: |
|
-XX:PermSize=16m (1.4) |
-XX:+ServerApp
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 refer to whether this set enhances the performance of your application before you use the option in production.
-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 performance when the New space is large and/or when your
application keeps a very low percentage of objects.
-XX:+UseCompilerSafepoints
Enables compiler safe points. In this version, compiler safe points
is off by default. Enabling compiler safepoints guarantees
a more deterministic delay to stop all running java threads before
doing a safepoint operation, namely garbage collection and deoptimization.
Note that currently a patch is needed. Refer to Known Problems these release notes for further information.
-XX:+UseOnStackReplacement
Enables on stack replacement. In this version, on stack replacement
is off by default. On stack replacement enables the interpreter
to go into compiled code while it is executing the same instance of the
method call. For example, if the VM is executing a method that has
a loop with a large number of iterations, an intra-method hotspot will
occur. To get better performance, the method should run in compiled mode
instead of interpreted mode. If you enable on stack replacement,
you must enable compiler safe points (refer to the previous option).
HP specific options and features
Additional HP-specific documentation is provided in the HP-UX
Programmer's Guide at Programmer's Guide for Java™ 2.
Noteworthy HP specific options and features for Java 2 version
include the following:
These are described below.
-pa11 option
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.
PA1.1 binaries can be run on PA1.1 as well as PA2.0 systems; however, a PA2.0 binary can only run on a PA2.0 based system. HP includes two versions of the shared libraries comprising APIs and VMs.
The PA2.0 shared libraries are the default if you are running on a PA2.0 system. You can override the use of the PA2.0 shared libraries on a PA2.0 system by specifying the -pa11 flag.
On a PA2.0 based system, if you invoke Java as follows, the default PA2.0 shared libraries are used.
java -version
If you invoke Java with the -pa11 option as follows, the PA1.0 shared libraries are used.
java -pa11 -version
-Xeprof option
Generates profile data for HPjmeter. Enables profiling of Java applications
running on HotSpot version 1.2.2.05 or greater and collects method clock
and CPU times, method call counts, and call graphs. For more information
on HPjmeter, refer to
Java™ Technology Software on HP-UX
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 refer to 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.
-Xprep
Dynamically preprocess (modifies) bytecodes of the classes loaded
by the JVM. The 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.
When the -Xprep option is specified, before loading the application
classes, the Java VM will load the specified factory class
and execute its method declared as:
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 JVM 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 JVM.
For each subsequently loaded class, the JVM 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 JVM as the replacement of the original version
of the class. If null is returned, the original version of the class will
be used.
-Xverbosegc<options>
Prints out detailed information about the spaces within the Java heap
before and after garbage collection.
The syntax is
-Xverbosegc usage: -Xverbosegc[:help]|[0|1][:file=[stdout|stderr|<filename>]]
:help prints this message.
0|1 controls the printing of heap information:
0 Print after every Old Generation GC or Full GC
1 (default) Print after every Scavenge and Old Generation GC
or 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 20 fields are printed:
<GC: %1 %2 %3 %4 %5 %6 %7 %8 %9 %10 %11 %12 %13 %14 %15 %16 %17 %18 %19 %20>
For a detailed explanation of the fields in the -Xverbosegc:help output, refer to
-Xverbosegc Help for Java™ 1.4.1 and 1.4.2
In addition we recommend HP's garbage collection analysis tool HPjtune,
which displays information contained in an Xverbosegc log graphically.
HPjtune is available at no cost from Java™ Technology Software on HP-UX
For documentation on the new garbage collectors, refer to
"Tuning Garbage Collection with the 1.4.2 Java Virtual
Machine" at http://java.sun.com/docs/hotspot/gc1.4.2/index.html.
An additional source of information is the white paper
"Improving Java Application Performance and Scalability by Reducing
GC Times and Sizing Memory using JDK 1.4.1" by Nagendra Nagarajayya and
J. Steven Mayer at
http://wireless.java.sun.com/midp/articles/garbagecollection2/
New garbage collectors: parallel and concurrent mark and sweep
Beginning with version 1.4.2 JavaSoft has implemented new generational collectors
that emphasize the throughput of the application or low garbage
collection pause times.
For a detailed look at garbage collection and the new collectors,
refer to JavaSoft's documentation "Tuning Garbage Collection with the 1.4.2
Java Virtual Machine" at http://java.sun.com/docs/hotspot/gc1.4.2/index.html.
Allocating physical memory and swap in the Java heap
Starting in 1.4.1.05, the method of allocating physical memory and swap within the Java heap was changed. As a result you are likely to see higher RSS (resident set size) memory usage when monitoring your Java processes with Glance or other tools, or your application startup may be slightly slower.
For more details on why this occurs and for examples of using key command line options, refer to: .
http://docs.hp.com/en/JAVAPROGUIDE/expanding_memory.html
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 1 GB to around 1.7 GB.
HP-UX 11.0 PA-RISC
With the installation of the required patches shown below (or their superseded
patches), 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)
Refer to also Application Dependent Considerations When Using Large Heap Size in these release notes.
Expanding heap size in native applications in HP-UX 11.23 (11i v2) Itanium
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. On HP-UX 11.23, by using HP-UX's EXEC_MAGIC linked with "-N"
you can expand your available memory space from 1 GB to around 1.7 GB.
This functionality is not supported on HP-UX 11.22 (11i v1.5.)
HP-UX 11.23 Itanium
No patches are required.
Refer to also Application Dependent Considerations When Using Large Heap Size in these release notes.
Expanding heap size in HP-UX 11.11 (11i v1) PA-RISC
Hotspot 1.4 now supports heaps up to 3.8 GB on HP-UX 11.11 with
the installation of the patch shown below.
For Java technology invoked from the command line on HP-UX 11.11, Java
automatically chooses an appropriate executable.
Required patch: PHKL_28428 (or its superseded patch)
- For heaps less than 1500 MB, the executable is 'java'
- For heaps greater than or equal to 1500 MB, and less than 2400 MB
the executable is 'java_q3p'.
- For heaps of 2400 MB to 3.8 GB, the executable is 'java_q4p'.
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 3000 MB, either new space (-Xmn) or old space
(-mx minus -Xmn) must be approximately 850 MB or less.
Refer to also Application Dependent Considerations When Using Large Heap Size.
Expanding heap size in HP-UX 11.23 (11i v2) Itanium
Hotspot 1.4.1.05 running in 32-bit mode now supports heaps up to 3.5 GB
on HP-UX 11.23. For Java invoked from the command line on HP-UX 11.23,
Java will automatically choose an appropriate executable. This functionality
is not supported on HP-UX 11.22 (11i v1.5.)
- For heaps less than 1500 MB, the executable is 'java'.
- For heaps greater than or equal to 1500 MB to 3.5 GB, 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.
Refer to also, 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 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.7 GB heap, but this does not necessarily mean it's going
to work correctly.
For example, if you use a 1 MB stack size (-Xss1m), and there are about 80 threads
in the process, you will have 80 MB for stacks. If you have native libraries, you
would probably add another 64 MB for C heap. You have now used a total of 144 MB 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.
Using WDB to examine backtraces in Java thread stacks
You can now use HP's debugger WDB 3.0.01 or later (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 Shared Library libjunwind.sl (PA), which is in the SDK.
The default location of the Java Unwind Library in the SDK is:
/opt/java1.4/jre/lib/PA_RISC/server/libjunwind.sl
/opt/java1.4/jre/lib/PA_RISC/server/libjunwind.sl
/opt/java1.4/jre/lib/PA_RISC2.0/server/libjunwind.sl
/opt/java1.4/jre/lib/PA_RISC2.0W/server/libjunwind.sl
/opt/java1.4/jre/lib/IA64N/server/libjunwind.so
/opt/java1.4/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 export GDB_JAVA_UNWINDLIB=/opt/java1.4/jre/lib/\
PA_RISC2.0W/server/libjunwind.sl
For 64-bit Itanium 2 machines:
export GDB_JAVA_UNWINDLIB=/opt/java1.4/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.4"
in the above commands. Then use WDB as usual to debug your Java
applications or core files. Refer to the tutorial slides on Debugging at
Performance Tuning, Tutorials, & Training
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.
The following Asian Locales are now supported by HP's 1.4 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.big5 |
|
Traditional Taiwan Chinese with Big5 encoding |
|
| zh_TW.eucTW |
|
Traditional Taiwan Chinese with CNS11643 encoding (planes 1-3) |
|
| zh_HK.hkbig5 |
|
Traditional Hong Kong Chinese with Big5 HK encoding |
For further information on the topics shown below, refer to
"HP-UX Fonts and the Java Runtime Environment" at HP-UX Java™ Information Library
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 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 the Java program returns, until the process is restarted.
If your application requires that system time changes are immediately
reflected, 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.
Profiling capability added
In the SDK Version 1.4, 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 be aware that using this option also turns off the
SIGQUIT handler, and you therefore cannot get a Java stack trace.
Signal chaining functionality (PA and Itanium)
The SDK 1.4 has a new feature for chaining an application's signal handlers
behind the JVM's signal handlers. With signal chaining functionality,
applications can now use signals that the JVM uses and they will not interfere
with the JVM's functionality. To obtain this functionality on PA-RISC, you
need to install a patch (described below).
For signal chaining functionality, the application must load the library libjsig.sl before libc.2.
The libjsig.sl or libjsig.so library takes care of signal chaining when
the application's signal handlers are installed before or after the JVM's
handlers get installed. The libjsig.sl or libjsig.so library is not needed
when the application installs the handlers before the JVM installs its handlers.
There are two cases to consider.
- Native application creates a JVM
The application can either link in libjsig.sl or libjsig.so
and ensure that libjsig gets loaded before libc.2 by linking them
in the correct order. Or you can use the LD_PRELOAD functionality
provided by the linker to load libjsig.sl or libjsig.so first.
- Normal JAVA application invoked from the command line
In this case LD_PRELOAD must be used. Linking the native libraries
with libjsig.sl or libjsig.so will not work because the JVM will load
libc.2 before the application's shared libraries get loaded.
For example, to use the LD_PRELOAD environment variable:
export LD_PRELOAD=<libjvm.sl dir>/libjsig.sl; java_application (ksh)
setenv LD_PRELOAD <libjvm.sl dir>/libjsig.sl; java_application (csh)
On PA-RISC, to obtain the LD_PRELOAD functionality, you need to
install the patch shown below.
- HP-UX 11.00 PA-RISC systems, install patch PHSS_28434 (or the patch
that supersedes it)
- HP-UX 11.11 PA-RISC systems, install patch PHSS_28436 (or the patch
that supersedes it)
For more information on signal chaining, refer to http://java.sun.com/j2se/1.4/docs/guide/vm/signal-chaining.html
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.
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 loaded at
the back end. 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 and Itanium)
If you have a thread performing an accept or read/write on a socket, and you
try to close the socket to clean up resources, the default behavior is for
the close() to block until the accept or read/write call completes. If you want to change this behavior, you can use the following Java command line option:
-XdoCloseWithReadPending
This option allows a thread to close a socket when there is an outstanding
accept or read pending on the same socket from another thread.
With the -XdoCloseWithReadPending option, the socket close() call closes
the socket and, in the context of the thread with the pending read or
accept, a SocketException with the message "Socket closed" is thrown.
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.
Compatibility with previous releases
Sun Microsystems maintains upward compatibility, therefore
an application written for a 1.3 JVM will run on a 1.4 JVM.
Downward compatibility is generally not supported,
because new API's are introduced that cannot be run on earlier JVMs.
For a detailed description of the incompatibilities between 1.3 and 1.4,
refer to http://java.sun.com/j2se/1.4/compatibility.html
Additional documentation
Java man pages located at /opt/java1.4/man
|
