Let me lead off with what I consider the single biggest win associated with IBM's 32-bit JVM offering for the System i: Most customers can now run WebSphere Application Server (WAS) without the huge memory overhead that the old 64-bit Java Virtual Machine requires. This is a big, big deal! Finally, IBM should be able to offer the System i as a WAS workhorse, head to head in competition with other application server platforms, without the bad news of increased cost because of a substantially larger required memory footprint. You can use the 32-bit JVM, which IBM has named IBM Technology for JVM, starting with V5R4. To use it with WebSphere, you need WAS 6.1 (or later).

The Story of System i Java (Abridged)

The tale, for the uninitiated, goes like this: Starting with V4R2, the best Java implementation on the planet was on the System i, and it got better and better with every OS release. The JVM was a 64-bit implementation (on a 64-bit platform, after all), and it was snazzy! It lived below the technology-independent machine interface (TIMI) for that close-to-the-hardware performance advantage. It garbage-collected objects asynchronously, taking advantage of multiple processors when possible. It interpreted Java bytecodes as did other JVMs, but it also executed code compiled into directly executable (DE) objects.

In the long run, the good things about the unique implementation on the System i became negatives. Garbage collection that isn't quite like that of other platforms means an unfamiliar playing field for those coming to the System i from elsewhere. A below-the-TIMI JVM construction makes new Java releases harder for IBM to implement and advances from other JVMs more time-consuming for IBM to port. Undoubtedly, there is also considerable expense involved in reinventing the wheel for the System i.

At one time, those DE-compiled Java objects were considered the height of excellence. Other JVM implementations with runtime interpreters or just-in-time (JIT) compilation couldn't touch the optimized performance of a precompiled Java class. Times have changed, however, and in current JIT implementations, optimization plans are retained and techniques are employed to focus optimization on most-used methods. Add to this an average 10 percent raw performance improvement associated with using the 32-bit JVM on the System i, and the performance advantage of DE objects is gone for good.

IBM now refers to the original 64-bit System i JVM as the Classic JVM. The new 32-bit JVM, as I mentioned, is called IBM Technology for JVM, and it executes under the Portable Application Solutions Environment (PASE). The base code for the implementation is from AIX (there are a few optimizations and customizations for the System i). A common set of base code means that very little platform-specific investment is needed on IBM's part. The advantage for customers is that improvements, fixes, and new Java releases should come to the System i faster, and they should be more consistent with other platforms.

IBM has promised a 64-bit version of IBM Technology for JVM for the System i (currently slated for release later this year with V6R1) to complement the 32-bit offering. When IBM delivers that version, Java support on the platform will be completely in line with IBM's offerings for AIX and Linux. We should expect the Classic JVM to have a limited life span, but its retirement date is as yet unknown.

Configuration

IBM Technology for JVM is available in V5R4 as licensed program product (LPP) 5722-JV1, option 8. PASE, installable as LPP 5722-SS1, option 33, is also required.

IBM Technology for JVM is an implementation of Java 2 Platform, Standard Edition 5.0 (J2SE 5.0). Installing IBM Technology for JVM does not prevent you from having one or more versions of the Classic JVM installed, including the Classic JVM version of J2SE 5.0 (LPP 5722-JV1, option 7). The key is learning how to tell the system which JVM you want to use.

If you do nothing, and a Classic JVM version is installed, it is used as the default JVM. To use IBM Technology for JVM, add an environment variable for JAVA_HOME and specify the path to the JVM:

ADDENVVAR ENVVAR(JAVA_HOME)
    VALUE('/QOpenSys/QIBM/ProdData/
        JavaVM/jdk50/32bit')
LEVEL(*JOB)

The LEVEL parameter indicates that we are setting this environment variable only for the current job (i.e., only the current job will use IBM Technology for JVM). To set the environment variable in a persistent fashion across the system -- making IBM Technology for JVM the systemwide default -- use this command:

ADDENVVAR ENVVAR(JAVA_HOME)
    VALUE('/QOpenSys/QIBM/ProdData/
       avaVM/jdk50/32bit')
LEVEL(*SYS)

Inside the QSH or QP2TERM shell terminal environments, set the environment variable for the current terminal session with an export, like this:

export -s JAVA_HOME=
    /QOpenSys/QIBM/ProdData/JavaVM/jdk50/32bit<

At any time, you can determine which JVM you are using by executing inside a shell terminal the java command with the -version option. With IBM Technology for JVM, you see something like this (look for "IBM J9 VM"):

java -versionjava version "1.5.0"
Java(TM) 2 Runtime Environment, Standard . . .
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2 . . .
J9VM - 20070420_12448_bHdSMR
JIT - 20070419_1806_r8
GC - 200704_19)
JCL - 20071511-SR5

The Classic JVM is much less verbose (look for "Classic VM"):

java -version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard . . .
Classic VM (build 1.5, build JDK-1.5, native . . .

With IBM Technology for JVM set as the job, shell terminal session, or systemwide default, you can still use the Classic JVM with the addition of the java.version property to your java command:

java -Djava.version=1.4 MyClass

Considerations

A 32-bit JVM means that memory overhead is lower (each object reference takes half the memory), but it also means that an application's available memory, or heap size, is limited to 4 GB. Because the JVM also uses heap storage, the practical heap size upper limit for an application running in a 32-bit JVM instance is said to be more like 3 GB. If you know that your application or WAS server instance requires more memory than this, you need to stick with the Classic JVM for now. (The Classic JVM has a heap size limit north of 240 GB.) If you don't know the heap size requirement of your application or WAS server instance, see "Determining Heap Size Requirements," below.

Several i5/OS commands are not supported in conjunction with, or do not apply to, IBM Technology for JVM. The Analyze Java Virtual Machine (ANZJVM) and Dump Java Virtual Machine (DMPJVM) commands are not supported. This is a shame, because these tools offer a quick and easy way to see "inside" a JVM instance. Create Java Program (CRTJVAPGM), the utility for creating a DE object does not apply to the new JVM technology. Therefore its adjunct, Display Java Program (DSPJVAPGM), serves no purpose either.

In the Classic JVM, Java programs compiled into DE objects can adopt authority. Because there is no such thing as a DE object in IBM Technology for JVM, adopted authority is not supported there.

Under IBM Technology for JVM (as with the Classic JVM), database access is available by means of the IBM Toolbox for Java (JT400 or JTOpen) JDBC driver or the native JDBC driver. There are no special considerations when calling RPG programs using the Toolbox, but native method invocation requires that your code be compiled for the teraspace storage model (for more information about the teraspace storage model, see publib.boulder.ibm.com/infocenter/iadthelp/v6r0/index.jsp?topic=/com.ibm.etools.iseries.debug.doc/concepts/cbiterra.htm [2]). For C modules, compiling for this storage model is straightforward; specify the following parameters on your CRTCMOD command:

TERASPACE(YES) STGMDL(*TERASPACE)
    DTAMDL(*LLP64)

The RPG compiler does not allow you to explicitly specify the storage model, but since V4R4, our RPG programs have been compiling as teraspace compatible.

In my testing, I was unable to get any of my own native method invocations (with both RPG and C libraries) to succeed under IBM Technology for JVM, although they work fine with the Classic JVM. The problems were not storage-model-related, and I have to assume that PTFs to fix things will be available by the time you read this. The Java Group PTF (SF99291 in V5R4) provides accumulated updates and fixes for both the Classic JVM and IBM Technology for JVM.

Complications

One of the glorious things about the Classic JVM is that garbage collection generally works fine without your having to think about it. If you've ignored garbage collection in the past under the Classic JVM, you do so at your peril when using IBM Technology for JVM. Now, garbage collection policies (there are four to choose from) govern how garbage collection works. None of them functions just like the Classic JVM garbage collection did, and you should not expect that the default will meet all your needs. Depending on the kind of work that a Java application performs, you need to choose an appropriate garbage collection policy and configure the JVM for it accordingly.

The default garbage collection policy optimizes for throughput, and it uses a stop, mark, sweep, and compact approach (your application threads are stopped while garbage collection is occurring). Another option lets you optimize for less thread-stop time, which might reduce overall throughput but can increase an interactive or sockets-based application's availability and level out its performance. Other options exist for applications that create a large number of temporary objects and for performance optimization through symmetrical multiprocessing (this last option is recommended only for systems with at least 16 processors).

This more complex garbage collection policy stuff has an upside. After you understand the policies and learn where and how to apply them, you will have acquired a transferable skill and will be equipped to run your application on AIX, Linux, and just about anywhere else.

Wrap-Up

Refer to Find Out More, below, for information about two great IBM Redbooks that help you with all aspects of the IBM Technology for JVM offering.

The addition of IBM Technology for JVM on the System i is a much-needed advancement. It can reduce the overhead and increase the performance of regular Java applications. Even more significant, the frustration of needing extra resources to run WebSphere on our platform of choice is finally at an end.

Dan Darnell is the author of the book Java and the AS/400 Second Edition (published by 29th Street Press), and an independent consultant in Little Rock, Arkansas. You can reach Dan at dan.darnell@sbcglobal.net [3].

DMPJVM JOB(090123/DAN/QJVACMDSRV)

DMPJVM JOB(090100/QEJBSVR/DANSVR)