1.1 tools, environment variables, and options
The HP-UX Developer's Kit for Java™ includes all the standard Java™ tools and options and
provides some HP enhancements. The Sun Microsystems' tools pages and the HP-UX specifics are given below.
A Java™ source code file has a .java extension.
The javac command compiles a Java™ source code file,
for example javac
hello .java.
The compiled program is saved as bytecode, for example
hello .class.
The java command executes the program,
for example java hello .
HP specifics
The HP-UX Developer's Kit for Java™ tools install into the /opt/java/bin
directory.
The installation process will update your system PATH to include
the /opt/java/bin directory to allow you to invoke Java™ applications.
Note: Beginning with release 1.15.05 for HP-UX 10.20 users,
the asynchronous garbage collector is no longer enabled by default. If
you want asynchronous garbage collection you need to specify the
-asyncgc option. The option -noasyncgc now does nothing. Note that use of asynchronous garbage collection usually impairs system performance.
-alljit option
You may use the -alljit option with the java or jre
with HP-UX Developer's Kit version C.01.15.01 or later versions.
The -alljit option will compile each method before it is executed
the first time. Naturally, compiling all methods initially will
slow down the execution until all compiling is complete.
This mode is useful for measuring the performance of a fully
compiled application.
-allocCacheSize=x option (hp-ux 11.0)
The HP-UX 11.0 java or jre option
-allocCacheSize=x controls the size of the cache per thread. x, the
size of the cache per thread, is set to 1 KB by default. By increasing
the size of the cache per thread, you reduce contention on the lock controlling access to the Java™ heap. However if the size of the cache per thread is too large, it may be difficult to find such a large block of contiguous space. When too large, you will see a compaction on every garbage collection when using -verbosegc. Since compactions are expensive, this can reduce your total throughput. In some large applications, setting x to 4 KB or 8 KB has increased
performance. The largest object allocated in the thread
local heap cache is one fourth the total size of the heap cache.
-compactInterval=<num> option
Use of compactInterval forces a Java™ Heap compaction when the time since the previous garbage collections is less than num, where num is a time specified in milliseconds.
Example: -compactInterval=300000 sets the compact interval to: 5 min * 60 sec/min * 1000 msec/sec and specifies that if the previous garbage collection occurred less than 5 minutes previously, then force a
compaction.
Use of compactInterval minimizes heap fragmentation by
compacting the Java™ Heap before the GC algorithm would normally trigger compaction. Minimizing fragmentation extends the time period between required garbage collections, but incurs the cost of the more frequent
compactions. Generally, the net effect on the program
is reducing the total time required to do garbage collections by the application.
compactInterval should only be used after experimenting with a variety of -mx values and studying the output from -verbosegc. Note that you must use -verbosegc to study the behavior of your program to determine
the impact of compactInterval on your program's behavior. We find that many applications run best when the heap is large enough that about 50% free space is reclaimed after each collection and those collections
occur infrequently. Additional performance may be gained by using compactInterval. Specifying an interval that is too _LARGE_, however, will degrade performance by performing far more compactions than necessary. You will typically need several iterations of testing using
-verbosegc to find the best compactInterval value.
-DclientAutoPlacement=true option (version C.01.18.00)
The version 1.1.8 java and jre command line option
-DclientAutoPlacement=true supports the new system property "clientAutoPlacement" which provides Motif-style window placement. If the property is set to true, windows with an unspecified screen location
will be positioned the same way as by the Motif window manager.
For example:
java -DclientAutoPlacement=true
will place pop-up windows that have no screen location specified in the program at a location on the screen that the Motif window manager chooses. If set to false (the default), the pop-up window will be located a
(0,0) on the screen.
-deferloop option
-deferloop defers compilation of methods containing loops. The default JVM behavior is to compile all methods containing loops before executing them. This behavior is based on the belief that most of the time
spent in program execution is spent in loops and that
the time taken to compile the loop before execution is regained during program execution. However, this also means program start-up can be slower. Use of deferloop puts these methods with loops in the queue to compile
while program execution continues.
-doCloseWithReadPending option (version C.01.18.00)
The version 1.1.8 java and jre command line option
-doCloseWithReadPending allows one thread to close() a socket when there is an outstanding read pending on that same socket from another thread. The default behavior when close() is called on a socket which has
an outstanding read call from another thread is for the close() to block until the read call completes. With the -doCloseWithReadPending option, the socket close() call closes the socket and, in the context of the thread with the pending read, a SocketException with the message "Socket closed" is thrown.
-eprof option (version C.01.18.00)
The java or jre option -eprof provides enhanced profiling that extends the Java -prof option, clock time and call count, by improving performance 10-100 fold and adding per thread collection of metrics
and method CPU time. CPU time is essential for determining bottlenecks in CPU-bound Java™ applications. Object creation count and the location where created are available through the HPjmeter tool.
The -eprof option will cause the JVM to write a java.eprof file when the process is shut down (System.exit()). (Killing the process will not cause the JVM to write out the java.eprof file; therefore,
instead of terminating the process running the JVM with
a kill signal, be sure to modify your application so that you create a thread which will run for a period of time and then call System.exit().
-green and -native option (HP-UX 11.0)
JDK 1.1 users with HP-UX 11.0 have the choice of running either the kernel-threaded or the green-threaded Java™ Virtual Machine (JVM) for
their Java™ applications. By default, the java command on HP-UX 11.0 uses the kernel-threaded JVM. Native threads give much better performance for your Java™ application. Scalable performance on multi-processors is only possible when using native threads.
To override the default: Set the THREADS_FLAG environment variable to "green" or pass the -green option to the java, jdb, javac,
or javap commands to force the use of the green-threaded JVM. You may also use -green and -native with the appletviewer command -- for versions 1.1.6 and higher of the appletviewer you do not need -J as a
prefix to -green or -native.
The shell scripts in /opt/java/bin choose between the native and green
versions based on command-line arguments and environment variables.
Your system administrator can modify the .java_wrapper shell script in the
/opt/java/bin directory to change the default from "native" to "green."
The command line argument -green or -native takes precedence over the
setting of the THREADS_FLAG environment variable and the shell script.
-lazyswap option (hp-ux 11.0)
HP-UX 11.0 users may use the -lazyswap option with the
java or jre command to
instruct the Java™ Virtual Machine (JVM) to reserve
swap space only for the portion of the Java™ heap that is in use, and
to reserve more swap space only as the heap is grown.
On HP-UX 11.0, without the -lazyswap option, swap space for the maximum sized heap is reserved when the JVM is started. The maximum heap size is controlled by the
-mx flag, the default is 16 MB. The initial heap size
is controlled by the -ms flag, the default was 1 MB prior to release 1.1.7. At release 1.1.7, and for subsequent 1.1 releases, the default for -ms is 4 MB.
Enabling -lazyswap will allow you to run more JVMs on your
system, provided that they don't all need to grow their Java™ heaps to their
maximum size.
If the JVM is unable to obtain the necessary swap space
when it tries to grow the heap, it will throw an OutOfMemory exception.
The lazy reservation of swap space only applies to the Java™ heap.
In particular, the JVM still reserves swap space for the maximum size
of the Java™ thread stack area. This is different from the Solaris behavior.
The maximum is reserved because the failure to obtain the swap space can occur at
any write into the stack area and there is no mechanism in place for the
application to catch and recover from this failure (unlike the OutOfMemory
case).
If you used versions of the HP-UX Developer's Kit for
Java™ prior to 1.1.3.4, you may have had problems due to the large
stack sizes that were reserved in those earlier JVMs. As of 1.1.3.4
(and later releases), the default native thread stack size is 128 KB (prior
to that it had been 1 MB). The default Java™ thread stack is 400 KB.
The defaults can be controlled by the
-ss and -oss flags (for the native thread stack and the Java™ thread
stack respectively).
-moncache=NxM+I option (hp-ux 11.0)
The HP-UX 11.0 java or jre
option -moncache=NxM+I sets the monitor cache parameters.
N, the number of monitor caches, is set at 1 by default. M, the initial number of buckets
per table, is set at 128 by default. I, the table expansion size, is set to
16 by default (and expands by power of 2). Large server side applications
may get better performance with N set as high as 32 and M set at 128 or
higher. This option is available beginning with version 1.1.7.
Proper values for this option can result in dramatic improvements in application throughput. The JVM uses a cache of monitors, called the monitor cache. Each monitor is assigned to an object when locking of
that object is required. However, contention for the Monitor Cache can become quite high in a busy program. Splitting the Monitor Cache into multiple caches reduces contention on the JVM locks controlling
assignment of a monitor to an object. Suggested values
are 16x128, 16x256, and 32x256.
-montlscache=N option (hp-ux 11.0)
The HP-UX 11.0 java or jre option
-montlscache=N sets the thread local monitor parameters. N, the number of
thread local cache entries, is set to 8 by default. This option is available beginning with version 1.1.7.
The montlscache option reduces contention for assigning
a monitor to an object by creating a thread local cache of monitors. When set to the proper value, contention for the Monitor Cache lock is eliminated. Suggested alternative values are 16 and 32.
-nocatch option
-nocatch disables the Java™ "catch-all" signal handler.
Use this option to generate clean stack traces from native code.
-[no]ChldSIGIOs option (version C.01.18.00)
The version 1.1.8 java and jre command line option "-[no]ChldSIGIOs" allows users to determine whether child processes should receive SIGIO or not.
Child processes will not receive SIGIOs when you use -noChldSIGIOs. When java is invoked through JNI, there are instances when it is undesirable for a child process that has been forked to receive a SIGIO.
For example, some processes may hang when they receive this signal. Therefore, -noChldSIGIOs allows users to control the flow of events when they do not have control over the code of such forked processes.
-nojit option
The HP-UX Just-In-Time compiler for Java™ (JIT) included with the HP-UX
Developer's Kit for Java™ automatically
and efficiently converts bytecode to native machine instructions at runtime.
Only use the -nojit option with the java or jre command
to disable the JIT after you have determined that the compiled code is not executing correctly and you have verified the problem with the HP Response Center.
Disabled, the Just-In-Time compiler interprets all Java™ methods.
JIT_OPTIONS environment variable
The HP-UX Just-In-Time compiler for Java™ (JIT) included with the HP-UX
Developer's Kit for Java™ automatically
and efficiently converts bytecode to native machine instructions at runtime.
Only use the JIT_OPTIONS environment variable to disable the JIT after you have determined that the compiled code is not executing correctly and you have verified the problem with the HP Response Center.
The syntax for the JIT_OPTIONS environment variable in Korn shell notation is:
export JIT_OPTIONS="-nojit"
Disabled, the Just-In-Time compiler interprets all Java™ methods.
THREADS_FLAG environment variable (hp-ux 11.0)
JDK 1.1 users running with HP-UX 11.0 have the choice
of running either the kernel-threaded or the green-threaded Java™ Virtual Machine (JVM) for their Java™ applications. By default, the java command on HP-UX 11.0 uses the kernel-threaded JVM. Native (kernel) threads give much better performance for your Java™ application. Scalable performance on multi-processors is only possible when using native threads.
You can override the default by setting the THREADS_FLAG environment variable to "green":
In Korn shell:
export THREADS_FLAG=green
java MyJavaApplication
Java™ and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Hewlett-Packard is independent of Sun Microsystems, Inc.
|
