Languages have evolved from machine languages to assembly languages to third- generation languages (3GLs) to computer-aided systems engineering (CASE) and fourth- generation languages (4GLs). Object-oriented programming (OOP) languages extend the modularization capabilities of HLLs while offering OO inheritance and polymorphism. Inheritance and polymorphism provide significant flexibility and adaptability but cause a decrease in performance because the code for functions and subroutines is bound at runtime, taking up CPU. Each evolution of programming languages caused a decrease in performance while providing substantial improvements in application design. Decreased performance of an interpreted language like Java shouldn’t be something that holds you back, because plenty of optimization techniques have been developed to improve Java’s performance.

Java Optimization

Optimization techniques effectively reverse evolutionary improvements to programming languages. That’s not a bad thing, because this reversal is done not by the business programmer but by optimizing compilers and advanced Java Virtual Machines (JVMs). Basically, optimization techniques attempt to take high-level constructs, such as loops, function calls, and polymorphism, and replace them with good old straight-line machine code. IBM leads the Java-computer-science community in developing technologies that improve Java performance. A recent issue of IBM Systems Journal (Vol. 39, No. 1, 2000) is even dedicated to Java performance.

Performance Bottlenecks

There are five main problem areas in Java performance: interpretation, function invocation, instantiation, synchronization, and garbage collection. Interpretation is simply the dynamic conversion of cross-platform Java byte code into the machine language of the platform hosting the application. IBM, along with Sun, has improved interpretation of byte code by compiling it in real time. There are compilers available that batch-compile Java, thus creating platform-specific executables, but Just-In-Time (JIT) compilation techniques of IBM and Sun are now exceeding the performance of the batch-compiled Java executables.

The time required for function invocation is a problem that RPG IV programmers are already familiar with. RPG IV coders have to decide whether to bind at compile time or at runtime with service programs. With Java, all your functions are resolved at runtime. To

decrease the overhead of function invocation, IBM’s JVM, at runtime, replaces function invocations with inline code, but only if it ascertains that the inline code will be faster and that polymorphism is not being used on any function. The JVM’s efficiency in performing this task is one of the key differentiators of JVM performance.

Java is a completely OO language. Everything in Java is encapsulated with a Java class (an abstract data type). The process of creating those classes in memory is called instantiation and is resource-intensive, so the issue is really just the time it takes to find and allocate a slot of available memory. IBM created some advanced algorithms that substantially decreased the time it takes to instantiate objects in large-scale applications.

Java is also a thread-based language. A Java thread is basically a lightweight process that runs in the same job space as other Java applications, thus sharing the same memory area. The problem with sharing memory space is that two threads may try to access the same object in memory at the same time. To handle this object contention, you have to use a feature of Java called synchronization. Java uses synchronization behind the scenes all the time, and what IBM did to improve synchronization was twofold. First, so synchronization wouldn’t be necessary, it figured out ways not to have the contention. Second, it created innovative technologies for implementing synchronization.

Still, perhaps the biggest improvement of Java over C++ is that, with Java, you don’t have to manage memory. Java handles memory management for you with a process known as garbage collection. During intervals or idle CPU times, the JVM goes into your application memory space and frees memory allocated to objects that are no longer referenced. IBM’s lab for the SanFrancisco project found that Sun’s version of JVM’s garbage collection locked up its sample application for minutes. IBM improved garbage collection first by having it run in a background process so the application doesn’t freeze and second by improving algorithms for compressing freed storage, thus improving object instantiation.

Business-quality JVMs

IBM jumped on the Java bandwagon early on, but it soon found that Java did not run large- scale transaction-based applications well. IBM knew it had to fix that. And it did, because now IBM has the fastest and most robust JVM in the industry. If you are running Java business applications on Windows, for performance and reliability you should use IBM’s JVM, but, if you are running Java on the AS/400 or S/390, the same optimization techniques that IBM used to make Java run fast on Windows NT are already in your IBM “mainframe’s” JVM.

Don Denoncourt is a freelance consultant. He can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

---

MC Press books written by Don Denoncourt available now on the MC Press Bookstore.

		Java Application Strategies for iSeries and AS/400 Explore the realities of using Java to develop real-world OS/400 applications. List Price $89.00 Now On Sale