General Performance Improvements

The Java platform is arguably becoming the programming language of choice for Internet development. In fact, it has been used successfully for Internet development for quite a few years now. Still, many questions have been raised about the seriousness of Java within mainstream software application development. Most of the issues have centered on the language feature set and the performance measurement when compared with other languages such as C++. The number and type of features that are a part of the core language has been growing since the first version was released. Some still argue that there is more work to do on this front. The truth is that it might never be the language that everyone wants it to be. It never will be C++ or Smalltalk. From all accounts, it was never designed to be a replacement for these languages and therefore the comparisons are sometimes not justified.

The other questions arise regarding the performance of Java when compared to other major languages such as C++. Most of the performance comparisons made on Java compare it to this language in particular. Keep in mind that most people compare the features of the two languages as if C++ and Java are in exactly the same language class. Although both languages are widely used and offer rich libraries and object-oriented features, the languages are very different. This is especially true with respect to how the languages are compiled.

As you probably heard , Java is designed to be very portable. In other words, source code that is compiled on a Windows machine can run on a Solaris machine without any additional compilation. This can happen because the .class files that are created when the source is compiled are not dependent on any particular operating system. Each operating system that supports Java has what is called a virtual machine. This virtual machine is an intermediary between the bytecode that makes up the Java application and the operating system that the application depends on for resources. Inside the virtual machine, there is something called the interpreter. The interpreter analyzes the bytecodes in the application and helps translate them into something the operating system can execute.

In the past, this has generally meant taking a huge performance hit for the additional level of interaction by the virtual machine and the interpreter to gain more portability. This happens because some additional dynamic compilation and security checking must happen when the application runs, rather than being performed during the compilation process. When Java was first introduced, and even with the 1.2 release, there still was a substantial performance loss due to this dynamic compilation. The Just In Time (JIT) compiler attempted to alleviate this by compiling the bytecode the first time a bytecode was accessed and then using this compiled version rather than using the interpreter to evaluate the bytecode on-the-fly . This helped with some aspects, but introduced overhead at startup time, because the JIT compiler usually compiled the bytecode up-front or when the first access to the code happened , thus causing detectable pauses in execution of an application. The JIT was a major step forward, but more had to be done.

With the release of the SDK 1.3, the performance of the virtual machine has been dramatically increased, primarily due to the new HotSpot technology. This is discussed in detail in the next section. If you want to understand HotSpot, you should skip this section for now and come back to it later.

Before getting into the HotSpot technology discussion, there are a few general enhancements that are unrelated to the HotSpot and focus more on common performance issues that developers have dealt with in previous version of Java. These enhancements involve pieces of the Java language that are used extensively and can make a difference in most "real-world" applications. There are four general performance enhancements that typically affect all real-world programs. These general enhancements also are examples of changes that have been made throughout the SDK 1.3 version. This list is not an exhaustive list, but rather examples from different areas of the language. The four enhancements are

• Reduce Memory Footprint Associated with Strings

• JAR File Memory Usage Reduction

• Performance Enhancements in BigInteger

• Swing Class Loading

Each one of these is discussed in a little more detail in the following sections.

Reduce Memory Footprint Associated with Strings

Strings are used for almost every application you can imagine, especially business type applications. If you have ever run a memory profile on a Java application, you might have actually passed out from all the instances of the String class loaded in memory. Each object instance loaded has to use some memory for the representation and the String instances are no exception. Besides the memory footprint, there is also a performance issue with all these instances in memory. The garbage collection system has to work overtime trying to figure out if these instances can be collected and the memory they are taking up regained. There have been improvements in the overall internal structures to help with this and to reduce the size and frequency of creation of these new instances.

JAR File Memory Usage Reduction

The way JAR files are indexed in memory has been improved so that the memory cost of loading a JAR file has been greatly reduced. The class libraries in rt.jar , for example, occupied about 420KB of memory when loaded in version 1.2, but require only about 100KB in version 1.3.

Performance Enhancements in BigInteger

Previously, implementation for the BigInteger class was based on an underlying C library. The new implementation performs all standard operations much faster than the old implementation. The speed-up realized in the new implementation can be as much as 5x or more, depending on the operation being performed and the length of the operands.

Swing Class Loading

In version 1.2 and before, if an application used any of the classes from the Swing libraries, these classes were loaded into memory regardless of whether they were accessed right away. In version 1.3, loading of some of the Swing classes is delayed until they are actually needed by the runtime environment. The delay improves startup time of applications that use the Swing libraries.