Migrating Java Applications to HP-UX

19
-Xgcpolicy:gencon
Generational and concurrent. Generational collector with a concurrent mark phase.
-Xgcpolicy:subpool
Similar to default policy optthruput, but employs an allocation strategy intended to perform better
on machines with 16 or more processors. (available on pSeries and zSeries)
If on IBM's JVM, your application is running with "optthruput", then try the default basic GC
policy on HP-UX.
If your application is running with "optavgpause" on IBM, then you can try CMS
(UseConcMarkSweepGC) on HP-UX.
If your application is running with "gencon," first try the basic GC policy on HP-UX and then
compare it to using CMS.
If your application is running "subpool," on a large multi-processor IBM machine, consider using
strategies listed in the section "Deployment of Java Instances and Processor Usage"
To determine the heap settings used on the IBM JVM, use the options:
-verbose:gc
or
-Xverbosegclog:<filename>
Note the Xverbosegclog option on the IBM JVM produces an XML file, and is different from the
-Xverbosegc option on the HP JVM.
Try to set comparable heap settings on HP-UX. Because there is no direct mapping between GC
policies from IBM to HP-UX, some experimentation and iteration will probably be necessary.
Confirm Garbage Collection Behavior using HPjmeter
Once you have your GC policies and GC parameters set, confirm that garbage collection is behaving
well by collecting GC output (Xverbosegc) and viewing the result in HPjmeter. See the section
“Collecting Garbage Collection Data for HPjmeter.”
The following are examples of some of the screenshots provided by HPjmeter to diagnose GC
problems.
Figures 10 - 12 illustrate serious GC performance problems. The Summary panel shows percentage
time spent in GC is 38%. Full GCs occur far too frequently, every 70 seconds on average. When
they occur, they are very long, averaging 26 seconds in duration: