Note: The default stack size for 1.4 64-bit mode JVM-
created threads is 1 MB. On PA-RISC 32 and 64-bit systems,
the default stack size is 64 KB. Therefore, if you are
using C language main programs that attach with JNI, you
will want to adjust the stack size to avoid overflows.
-XX:+AllowUserSignalHandlers
Using this command instructs the JVM not to complain if the application
installs signal handlers.
-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
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: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 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:MaxPermSize=<size>
Sets the maximum size of permanent 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:+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 see 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.3 is 64MB. Number
can include 'm' or 'M' for megabytes, 'k' or 'K' for kilobytes, and
'g' or 'G' for gigabytes. For example, 32k is the same as 32768.
-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.
For patch information, see "Known Problems" in these release notes.
-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 should also enable compiler safe points (see the previous section).
For patch information, see "Known Problems" in these release notes.
-XX:+UseSIGUSR2
Use the java command line option -XX:+UseSIGUSR2 if you want the JVM
to use SIGUSR2 for internal operations like Thread.interrupt() calls
instead of SIGUSR1, the default. This allows you to better implement
third party middleware applications that in some versions want to use
SIGUSR1 for similar purposes in their native code.
HP specific options and features
Additional HP specific documentation is provided in the HP-UX Programmer's Guide.
Noteworthy HP specific options and features for Java 2 version
include the following:
-pa11
-Xeprof
-Xnocatch
-Xprep
-verbosegc
-Xverbosegc
These are described below.
-pa11 option
HP's PA-RISC 2.0 architecture offers performance features not compatible
with previous architectures. PA1.1 binaries can be run on 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. The user can override the use of the PA2.0 version of the
shared libraries on a PA2.0 by specifying the -pa11 flag. For example:
On a PA2.0 based system, invoking Java by typing
java -version
results in something similar to:
java version "1.4.0"
HotSpot VM (..., mixed mode, PA2.0 build 1.4.00-00/04/23-PA_RISC 2.0)
The generated version string indicates that the PA2.0 version of the
VM will be used.
You can override the use of the PA2.0 version of the VMs and APIs on a
PA2.0 system by adding the -pa11 flag as follows:
java -pa11 -version
This results in something similar to:
java version "1.4.0"
HotSpot VM (..., mixed mode, PA1.1 build 1.4.00-00/-4/23-PA_RISC 1.1)
The version string indicates that the PA1.1 version of the VM in spite of
the fact that 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
the HPjmeter overview and features page).
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
-Xnocatch
The -Xnocatch option disables the Java "catch-all" signal handler.
Use this option to generate clean stack traces from native code.
-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.
-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 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.
-Xverbosegc<options>
To better understand how garbage collection works in the HotSpot JVM, we recommend the article
"Improving Java Application Performance and Scalability by Reducing Garbage Collection Times and Sizing Memory Using JDK 1.4.1" (November 2002) by Nagendra Nagarajayya and J. Steven Mayer. The article describes garbage collectors in SDK 1.4.x, however it also covers the older collectors used in 1.3.x.
In addition, we recommend HP's tool HPjtune, which graphically displays information contained in an Xverbosegc log.
This option prints out detailed information about the spaces within
the Java Heap before and after garbage collection.
The syntax of the option is:
FastSwing
FastSwing is an HP feature which provided significant performance
improvement for Swing Applications on a Remote X-Server. In
this release, the FastSwing option is ignored by the
HP SDK 1.4.0. The Java 1.4 performance enhancements provide
out-of-the-box performance for both local and remote displays,
equivalent to FastSwing. For more information on 1.4
performance enhancements, see:
http://java.sun.com/products/java-media/2D/perf_graphics.html
large java heap sizes (32-bit): expanding heap size in native apps
(hp-ux 11.0 and 11i)
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 11i, 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
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_20228, PHKL_23409, PHKL_26800, PHKL_26136
For 1500MB to 1900MB* of Java heap:
chatr +q3p enable <executable name>
*In our next 1.4 release, this number will be 2400MB.
hp-ux 11i
With the installation of the required patch shown below (or its
superseded patch), you can get larger Java heap by using the commands below.
Required Patch: PHKL_25614 (or its superseded patch)
For 1500MB to 2400MB of Java heap:
chatr +q3p enable <executable name>
For 2400MB to 3 GB* of Java heap:
chatr +q3p enable +q4p enable <executable name>
*In our next 1.4 release, this number will be 3.8 GB.
See also "Application Dependent Considerations When Using Large Heap Size" in these release notes.
large java heap sizes (32-bit): expanding heap size (hp-ux 11i)
Hotspot 1.3.1 now supports heaps up to 3.0 GB 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_25614 (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.0 GB*, the executable is 'java_q4p'.
*In our next 1.4 release, this number will be 3.8 GB.
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 (32-bit)
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.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, and have 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 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
(NOTE that for this release, this feature is available in 32-bit mode only.)
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, 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_RISC2.0/server/libjunwind.sl
For example, in ksh, you should set the environment variable like this:
export GDB_JAVA_UNWINDLIB=/opt/java1.4/jre/lib/PA_RISC/server/libjunwind.sl
(if you use PA1.1 machines), or
export
GDB_JAVA_UNWINDLIB=/opt/java1.4/jre/lib/PA_RISC2.0/server/libjunwind.sl
(if you use PA2.0 machines).
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. 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.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 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
Since SDK 1.2.2.09 and SDK 1.3.1, 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 Java returns, until the process is restarted.
If your application requires that Java immediately reflects 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.
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 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.
signal chaining functionality
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 not interfere
with the JVM's functionality. To obtain this functionality, you
need to install a patch (described below).
For signal chaining functionality, the application must load the library
libjsig.sl before libc.2.
libjsig.sl takes care of signal chaining when the application's signal
handlers are installed before or after the VM's handlers get installed.
libjsig.sl 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 and ensure that
libjsig.sl gets loaded before libc.2 by linking them in the right
order or use the LD_PRELOAD functionality provided by the linker
to load libjsig.sl first.
- Normal JAVA application invoked from the command line
LD_PRELOAD must be used in this case. Linking the native libraries
with libjsig 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)
To obtain the LD_PRELOAD functionality, you need to install the patch
shown below.
HP-UX 11.00 systems, install patch PHSS_26559
HP-UX 11.11 systems, install patch PHSS_26560
For more information on signal chaining, go 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.
manually launching the application VM
(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 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
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 should use the following
Java command line option:
-XdoCloseWithReadPending
This option allows one 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.
C and C++ libraries
Libraries compiled with the cfront HP C++ compiler will not work with HotSpot.
HotSpot requires use of the HP aC++ compiler for any application C++
libraries loaded dynamically at runtime.
JAR files
If you run an applet from a JAR file, the classes files should only be
available in the JAR file, and the JAR file should not be in the class path.
compatibility with previous releases
Sun Microsystems maintains upward compatability (except for noted
incompatabilities). Therefore an application written for 1.3 will
run on a 1.4 JVM. Downward compatibility is generally not supported,
since new API's are introduced that cannot be run in 1.3.
For a detailed description of the incompatibilities between 1.3 and 1.4,
go to:
http://java.sun.com/j2se/1.4/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.4 features and tools:
http://java.sun.com/products/j2se/1.4/docs/index.html
Java 2 SDK version 1.3 features and tools:
http://java.sun.com/reference/docs/index.html
Java 2 version 1.4 API Specification:
http://java.sun.com/products/j2se/1.4/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
problem fixes and known issues
Defects fixed in this release are shown below.
Known JavaSoft bugs are documented in the Bug Database at:
http://developer.java.sun.com/
defects fixed
JAGae25082 8606260760 fix embedded paths in libjvm.sl for 64-bit
JAGae08391 8606240356 heap Sizes > 1.8 GB not supported
JAGae19637 8606255310 X.509v3 KeyUsage for an SSL Server
JAGad97370 8606228313 Xverbosegc needs to be implemented
JAGae26546 8606262216 Xverbosegc fix the mark sweep invoke cause
known issues
Below is some information on known defects. Some of the solutions
require installing patches. For more information on locating and
installing patches, go to the patches page.
using the C++ (-AA) option (PA-RISC only)
If you are running HP-UX 11.0 or 11.11 PA-RISC, you cannot use the ANSI C++ standard (-AA) option in an application that loads Java. Starting with SDK 1.4.1.03, there is a workaround for this problem.
NOTE: This only affects PA-RISC systems; on Itanium systems, the C++ runtime libraries are designed to support -AA by default.
shl_load HotSpot libjvm problem due to TLS
The libjvm library for the HotSpot 1.4 JVM uses thread local storage (TLS).
Currently the dynamic loader that is used by shl_load does not support
dynamically loading a shared library containing TLS when the library
was not included in the link line.
You may have a need to load a library dynamically (using shl_load)
that contains TLS, for example libjvm.sl, without having linked your
application against it. For example, this might be the case if your
application uses plug-ins.
The current workaround is a new linker feature LD_PRELOAD that is
available for HP-UX 11.0 in patch PHSS_26262. For HP-UX 11i the feature
will be included in the next update release. For more information on
LD_PRELOAD functionality and its limitations, read the man page
for dld.sl AFTER you have installed the patch.
64-bit support—X/Motif
For 64-bit support on X/Motif, you will need to install one of the
patches shown below.
HP-UX 11.00 PHSS_25879 64-bit
HP-UX 11.11 PHSS_25881 32/64-bit
These fix GUI failures due to the window height
of some Java application pop-up windows being too large.
64-bit support—system call
The system call get__lwFastHighResolutionTimer() may fail.
For HP-UX 11.0, the workaround is to install the two patches
shown below. HP-UX 11i (11.11) system calls function correctly.
HP-UX 11.00 PHKL_26059 __lw_get_thread_times reports incorrect time
HP-UX 11.00 PHKL_26008 cumulative pstat patch
/dev/poll runtime support
For systems where /dev/poll runtime support is required, you
will need to install one of the following patches, depending
on your HP-UX version:
HP-UX 11.0 PHKL_24064
HP-UX 11i (11.11) PHKL_25468
HP 3D technology for the Java platform
In this release, HP 3D technology is not supported.We expect
to release the 3D technology in the near future.
HPjconfig configuration tool
Due to an incompatability between the Crimson XML parser included
in the 1.4 JVM and previous XML parsers, HPjconfig version 2.0 or
earlier will not work with 1.4 JVM. HPjconfig version 2.0.2
fixes this problem. It is available for download from the
HPjconfig Downloads and Documentation.
on stack replacement
NOTE: For both HP-UX 11.0 and 11i, using on stack replacement
requires a patch. The required patch numbers are shown below. For information on locating and
installing patches, go to the patches page.
HP-UX 11.0 PHKL_26059 PHKL_27089
HP-UX 11i PHKL_24751 PHKL_27092
In this version, on stack replacement is off by default.
To enable it, use the -XX:+UseOnStackReplacement option.
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 code while 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
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 the patches page.
HP-UX 11.0 PHKL_26059 PHKL_27089
HP-UX 11i PHKL_24751 PHKL_27092
In this version, compiler safe points is off by default. To turn it on,
use the -XX:+UseCompilerSafepoints option. Enabling compiler safepoints
guarantees a more deterministic delay to stop all running java threads
before doing a safepoint operation, namely garbage collection and
deoptimization.
secure socket layer (SSL)
When using an SSL connection to a web server, you need to run your Java application with the
additional option shown below. This is due to a defect, which will be fixed in the next 1.4 release.
-Djava.protocol.handler.pkgs="sun.net.www.protocol"
using linker option +noenvvar on Itanimum and PA-64 systems
If your application links with libjvm and uses the JNI
interface APIs to load the JVM directly, do not use the
linker option +noenvvar on Itanium or PA-64 systems. The
defect does not exist on 32-bit systems. It is expected
to be fixed in a future release.
running Java with setuid or setgid
Java requires dynamic loading (SHLIB_PATH, LD_LIBRARY_PATH) which are disabled in setuid or setgid executables. Therefore Java cannot run with setuid or setgid.
-Xincgc not supported on 32-bit PA
-Xincgc support is not available on 32-bit PA systems in this release; it will be available in a future version. The option works on 64-bit PA and IA.
legal notices
Copyright © Hewlett-Packard Company 2003
Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Sun Microsystems, Inc. in the U.S. and other countries.
|
|
