HP-UX Java™ SDK Version 1.3.1.01 Release Notes

It will lead you through the installation. Change Source Depot Type to "Local Directory" and Source Depot Path to /tmp/<filename>. (If you used a directory other than /tmp in the previous step, replace /tmp with that directory name.) We recommend you select the "Reinstall filesets" and unselect the "Mount filesystems" option from the options menu.

-Xbootclasspath:<bootclasspath>

-Xms<size>

-Xss<size>

-XX:MaxNewSize=<size> (not supported on 1.3) (excerpt from http://java.sun.com/docs/hotspot/VMOptions.html)

-XX:NewSizeThreadIncrease=<sizeInKb>

-XX:NewSize=<size> (excerpt from http://java.sun.com/docs/hotspot/VMOptions.html)

where <options> is a list of <key>[=<value>] arguments separated by commas.

file=<filename>

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.

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.

-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.

-Xverbosegc[:help]|[0|1][:file=[stdout|stderr|<filename>]]

:file=[stdout|stderr|<filename>] specifies output file

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 >

1: Indicates the cause of the garbage collection.
    -1: indicates a scavenge (during a scavenge only objects from
        the New space are collected)
    0-6: indicates a full garbage collection (during a full garbage
         collection objects from all areas are collected)
The code indicates the reason for the full garbage collection as follows:
    Reason:
    0:  Call to System.gc()
        The call was made by the application.
    1:  Old Generation full
        An object was to be allocated in the Old Generation, but there
        was no room there.
    2:  Permanent Generation full
        The heap area holding the reflection objects (representing Java
        classes and methods) was full.
    3:  Train Generation full
        Reserved for Java Virtual Machine developers
    4:  Old generation expanded on last scavenge
        Due to implementation reasons, if the Old Generation expanded
        on last scavenge, no more scavenges can be performed reliably
        before the next full garbage collection.
    5:  Old generation too full to scavenge
        An object was to be allocated in the New Generation, but there
        was no room there.  However, the VM has determined that the Old
        Generation was likely too full for a scavenge to compete without
        expanding the Old Generation.  Therefore a full garbage collection
        was performed rather than a scavenge.
    6:  FullGCAlot
        Reserved for Java Virtual Machine developers.
%2: The time elapsed between the Java program start and the start of this
    garbage collection event.
%3: Garbage collection invocation. This is the sequential number (count) of the
    garbage collection event. Counts of Scavenge and
    Full GCs are maintained separately. 
%4: Size of the object allocation request that forced the GC, in bytes.
%5: Tenuring threshold - determines how long the new born object
    remains in the New Generation.
    The report includes the size of each space:
       Occupied before garbage collection (Before)
       Occupied after garbage collection (After)
       Current capacity (Capacity)
All are in bytes.
Eden sub-space (within the New Generation)
%6:  Before
%7:  After
%8:  Capacity
Survivor sub-space (within the New Generation)
%9:  Before
%10: After
%11: Capacity
Old Generation
%12: Before
%13: After
%14: Capacity
Permanent Generation (Storage of Reflective Objects)
%15: Before
%16: After
%17: Capacity
%18: Duration of the garbage collection in seconds.

1. To install the Ricoh fonts, run /usr/sbin/ttinstall provided by the Japanese System Environment (JSE) on the WABUN/W31NT31 fonts. It will install the fonts to /usr/lib/X11/fonts/ttfjpn.st.
2. Add the Ricoh installation location to the JAVA_FONTS variable. The default is: JAVA_FONTS=/usr/lib/X11/fonts/ttfjpn.st/typefaces
3. Install the Ricoh font property file to $JAVA_HOME/jre/lib. Beginning with SDK 1.3.1 and later, the Ricoh property file is shipped. With proper (root) privileges, copy it to font.properties.ja as follows:
   su
   cd $JAVA_HOME/jre/lib/
   cp font.properties.ja.Ricoh font.properties.ja
4. Set LANG to the Japanese locale ja_JP.SJIS in your runtime environment, or simply use CDE locale login.

For 2400MB to 3.8GB of Java heap, use this command:

1. Remote debugging with the -attach or -listen jdb option.
2. You are implementing a debugger which uses the JDWP directly.
3. You are implementing a debugger back end which uses JVMDI.

1. The environment variable JAVA_FONTS is incorrectly set.
2. The Asian TrueType fonts/typefaces have not been installed.
3. The Java font property file for the Asian typefaces has not been installed. This file must correspond to your LANG setting and the typefaces.