i/OS 7.1 Marks a Change in the JVM Guard

July 14, 2010 Alex Woodie

There is one piece of news from IBM‘s i/OS 7.1 roll-out that didn’t generate a lot of attention in the System i community, but is important for programmers who develop in Java as well as their customers. Starting with i/OS 7.1, IBM no longer supports the “Classic” Java Virtual Machine (JVM) that Rochester developed years ago specifically for OS/400. This leaves the platform with two JVMs: one 32-bit and the other 64-bit. IBM says that performance and cross-platform compatibility will improve with the new JVMs, although some developers may need to fiddle with their apps to make them work.

For many years, IBM engineers in Rochester developed a proprietary JVM that worked only on the OS/400 and i5/OS operating systems and exploited some of its unique attributes, such as integration with ILE programs and utilization of the single level storage architecture.

This 64-bit JVM, which is now referred to as the Classic JVM, worked well for application developers targeting OS/400 V4R3 and above. However, despite the fact that Rochester used licensed Java code from Sun Microsystems to build the JVM, the JVM was nonetheless proprietary and required developers coming from outside of the AS/400-iSeries ecosystems to tweak their existing Java apps to get them to work well on OS/400 and i5/OS iron. This was a big concern because it basically eliminated the “write once run anywhere” benefit of developing in Java–arguably the big benefit over C++ (besides the fact that Java was not controlled by Microsoft). Developers and vendors coming from outside of the platform would still need to go through the work of porting their applications to run well on the AS/400-iSeries servers, and conversely, those who wrote Java specifically for the platform would need to tweak things when moving into the larger X64 world.

Beginning with i5/OS V5R4, which launched in January 2006, IBM introduced a new 32-bit JVM that was designed to address some of the shortcomings of the Classic JVM that had been in place for the previous eight years. It was also at this time that IBM told Java developers they would eventually need to move off the Classic JVM, as the new 32-bit JVM would become the standard.

Besides having a smaller memory footprint (as 32-bit programs tend to have), the new 32-bit JVM addressed some of the compatibility concerns. While IBM moved away from using Sun’s licensed codebase and instead developed the new 32-bit JVM using its own tools, the new JVM was the same one that IBM used on its System x and System p servers running Unix, Linux, and Windows, thereby partially re-instating Java’s big cross-platform compatibility benefit.

IBM quietly added a third JVM in 2008 with the launch of IBM i/OS 6.1. The new 64-bit JVM was based on the 32-bit JVM that IBM launched with i5/OS V5R4 two years earlier, and supported the same Java Development Kits (JDKs), versions 1.5 and 1.6, as its older and slimmer brethren. For the next two years, IBM would offer and support three JVMs for i/OS 6.1.

Bye Bye to a Classic

With this spring’s launch of i/OS 7.1, IBM has stopped selling and supporting the Classic JVM, and now only supports the two JVMs, which IBM refers to as “IBM Technology for Java,” or IT4J. IBM’s rationale for the move is that it boosts performance, simplifies maintenance tasks for IBM tool developers, and allows investments in those programming tools to benefit a larger audience. System i and i/OS-based Power Systems shops that license the IBM Developer Kit for Java will get only the new IT4J technology.

As with any transition, there are some pros and cons (mostly pros, according to IBM), and it will take developers some time to sort it all out. Since the uptake of i/OS 7.1 is expected to remain slow for the time being, the demand for i/OS 7.1-compatible programs from developers and independent software vendors (ISVs) will also be slow. IBM made bigger overall changes to the runtime with i/OS 6.1 that impacted a larger number of developers, including those writing in RPG, the dominant language on the platform. However, moving forward, any vendor that writes in Java or uses Java components will need to deal with the transition.

So, what are the differences between the old Classic JVM and the two IT4J-based JVMs currently supported?

For starters, the two new JVMs run in PASE, the AIX runtime environment that has been bundled into OS/400 and i/OS for many years, as opposed to running as a native i/OS program, like Classic JVM. Also, the new JVMs don’t use single level storage. Instead, they use what’s called the “terraspace storage” that’s used for PASE applications.

These changes have some drawbacks. To get their Java programs to work on i/OS 7.1, developers must re-compile their Java programs with terraspace storage enabled. Failure to do this will result in errors. Also, running in PASE mode can have an impact on performance compared to running in native ILE mode. For applications that require both types of access–which, ostensibly, is any i/OS Java application that touches DB2/400, which runs in ILE mode–developers should realize that traversing the ILE/PASE boundary sucks up CPWs.

Performance Impacts

How much of a performance hit the move to PASE and the need to traverse the PASE/ILE boundary entails can be gleaned from the recent benchmarks that IBM published for its new Power7 systems. Because the new 32-bit IT4J JVM is based on IBM’s Java development tools for AIX, and because the same hardware is used across the Power7 line, direct comparisons can be drawn between the results of the AIX- and Linux-based Power Systems servers and the i/OS-based Power Systems server when running the Java-based SPECjbb2005 benchmark.

The performance hit, according to the analysis of the SPECjbb 2005 numbers by IT Jungle’s own Timothy Prickett Morgan, is about 17 percent. (Editor’s note: This number is just a rough estimate, though, as the i/OS and AIX systems used in the benchmarks were not identical, as was previously reported; the AIX systems had twice the memory of the i/OS systems, which could have accounted for some of the difference. However, as TPM points out in a July 12 story, memory may not be as big of a performance factor for Java workloads on Power systems as other configuration details, namely, heap sizes.)

While there is a performance impact of running in PASE, the new 32-bit JVM is still faster than the Classic JVM, according to IBM. Big Blue says the same application running under the new JVM will perform about 20 percent faster than running under the Classic JVM on the same hardware. This mostly has to do with the fact that the newer 32-bit JVM sports about a 40 percent smaller memory footprint than the old JVM, which speeds up performance. A more sophisticated just in time (JIT) compiler also boosts performance, IBM says.

A new JDBC driver introduced with the 32-bit IT4J JVM minimizes, but does not entirely eliminate, the trips across the ILE/PASE boundary, according to IBM. This JDBC driver is written as PASE code, and is the best way to access DB2/400 with Java applications.

IBM says that, even with the performance hit of crossing the ILE/PASE boundary, the new 32-bit JVM still outperforms the old Classic. “Performance is, by far, the biggest reason for moving from the Classic JVM to the IT4J JVM,” says a Java expert in IBM’s Rochester lab. “It would be uncommon for someone moving from the Classic JVM to IT4J to not see some performance gain.”

While traversing the PASE/ILE barrier eats up some of the gains of the new JVM, the new Power7 chips make any differences almost moot. The changes that IBM made with Power7–including moving to eight-core processors, with four threads per core, and bigger memory caches on the chip–appear to be right up Java’s alley. Java really flies on the new Power7 chips.

IBM says that smaller Java applications should run just fine on the new 32-bit IT4J JVM on i/OS. According to IBM, applications that required 5 GB to 6 GB of memory on the old Classic JVM will actually become more efficient with memory under the new 32-bit JVM, and should run fine under the new JVM’s 3 GB limit. However, applications that require more than the 3 GB memory limit–or need more than about 1,000 processing threads–then it should be used with the 64-bit JVM. The bigger, heftier 64-bit JVM sucks up more memory than its 32-bit compatriot, which means it should only be used for larger applications that don’t fit in the 32-bit JVM.

Adopted Authority Not Welcome

While most developers will see a performance boost with the new 32-bit IT4J JVM (and even more when using Power7 iron), there are other concerns the new IT4J JVMs bring to developers, and a few “gotchas” as well.

The biggest concern may be that the new JVMs do not support adopted authority, which is an i/OS security concept that allows a program user to adopt the authority of the program owner–a technique that is useful for tasks such as changing a password. Since the JVM is no longer integrated with the system licensed internal code (SLIC) layer, IBM apparently felt it was too great a security exposure to permit adopted authority in Java programs to continue when SLIC does not have explicit control of the Java environment.

This should not come as news to i/OS Java developers, as IBM has been warning them about this change for years, and stopped allowing adopted authority with i/OS 6.1. IBM has provided tools with the new JVMs to detect and log when a Java program is attempting to use adopted authority. IBM has also provided several examples of how to integrate Java programs with i/OS user profile using native and Java-based techniques.

There are some other little gotchas that developers might experience when porting Java apps from the old Classic JVM to run under the new JVMs. And while the new JVMs do provide some i/OS-specific functions, it appears that using them could still complicate matters when trying to run the application on a non-i/OS JVM. Any i/OS Java application that crosses the ILE/PASE boundary will need to be rejiggered to run on a non-i/OS JVM, according to IBM.

The IBM Java expert says most applications written for the Classic JVM will require no changes to work under the new JVM (although there are a few that may). While there were some complaints of problems with the new IT4J technology, IBM has addressed those over the last couple of releases. “Our overall impression of the functional compatibility between the old Classic JVM and the new IT4J, is that it has exceeded our expectations,” he says.

As with anything in this world, progress does not come free. There is a price to pay (however small it may be) for the transition IBM is making with Java on the i/OS platform. Java applications that cross the PASE/ILE stack are not directly compatible with other JVMs. And when one considers that the Power7-based System p servers can run Java 17 percent faster than a Power-based System i platform, a Java developer might wonder to himself whether he would be better off running it on AIX instead.

For more information on the changes in Java with i/OS 7.1, visit IBM’s “IBM i Information Center” website at publib.boulder.ibm.com/infocenter/iseries/v7r1m0.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search