RE: Optimizing for Java and Tomcat (x-posted)

I think you should prefer 32 bit, and you should probably prefer Java 7 over Java 6. The J9 Java 7 JVM has a few performance improvements as well as a bunch more functions in the classes. Any customer with a machine big enough to favor the 64 bit machine is going to have someone on staff with enough knowledge to change your preference lookup script, I would think. As I see it, the 64 bit versions were done just so the FedEx's of the world could run WAS really fast on their really, really, huge machines with hundreds of gigs of memory (I don't know how big you can make these machines).

-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-
bounces@xxxxxxxxxxxx] On Behalf Of James H. H. Lampert
Sent: Thursday, November 21, 2013 5:10 PM
To: Java Programming on and around the IBM i
Subject: Re: Optimizing for Java and Tomcat (x-posted)

On 11/20/13 3:10 PM, Dan Kimmel wrote:

"Optimize" is a loaded term. I don't know of any methods to optimize,
though I know a few tricks to make java (and Tomcat) run faster.

First, run java in its own storage pool. There's a couple ways to do
this. I create a separate subsystem and allocate a pool to it. I
allocate either a private pool or one of the *SHRPOOLxx's. . . .

Would anybody happen to have a recommendation on a tutorial for this?

The J9 jvm's beat hell of the classic except in rare circumstances.
On older versions of the OS, that's usually what's known as the "32
bit" jvm. On newer systems, there's 64-bit versions of some J9's
depending on Java version.

At the moment, we have Tomcat running in the JVM at
/QOpenSys/QIBM/ProdData/JavaVM/jdk60/64bit
on a V6R1 box. The CL we use to start Tomcat has that as its first
choice, and failing to find it looks for (in this order):
/qopensys/QIBM/ProdData/JavaVM/jdk60/32bit
/qopensys/QIBM/ProdData/JavaVM/jdk626/64bit
/qopensys/QIBM/ProdData/JavaVM/jdk626/32bit
/qopensys/QIBM/ProdData/JavaVM/jdk70/64bit
/qopensys/QIBM/ProdData/JavaVM/jdk70/32bit
and takes the first one it finds. Should I change this to prefer 32-bit
JVMs over 64-bit?

--
JHHL