In the past six years or so the claim that Java is a slow language has regularly appeared in articles and news discussions. Most of the time I follow the debate, but after a while I get bored because the discussions remain at the micro-benchmark level. It continues to amaze me that there isn't more focus on system-level performance in discussions of language performance.

Having spent seven years actively interested in the field of runtime system optimization and the past four years designing a server-side JVM, JRockit, I am pretty convinced that micro-benchmark results cannot be extended to the system level, where performance really matters. Thus, I thought it would be interesting to give you a view of the performance issue from a JVM developer perspective. I'm arguing that Java is anything but a slow and inefficient language, and that the JVM is the key component ensuring that the system is as fast and easy to deploy and run as it was fast and easy to develop.

Performance Is Not a Micro-Benchmark
This is 2002 and people are still arguing that Java is a slow language. The most common argument comes from developers who have written small benchmarks in Java and then rewritten them in C and are touting how much faster the C programs are. I'm not writing this article to claim that they are wrong.

Of course they can write micro-benchmarks in a couple lines of Java code and redo the same benchmarks in C/C++ and the C programs will probably run faster than the Java programs. That's not where I disagree with them. I disagree with their conclusion; the results of a small micro-benchmark test cannot be extended to say anything about a large-scale application. I believe most systems will be built faster by fewer developers and they will even run faster if they are written in Java instead of C. Java is a language of scale; C is a language of micro-level performance. The development of Java is a natural result of the evolution of system development.

The System Development Evolution: From Punch Cards to Web Services
What has happened during the past 30 years or so is an explosion - the explosion of large-scale system development. There are so many developers in the world now, and they're building systems that are larger than what anyone imagined possible 30 years ago. In addition, application development today is no longer an I-build-every-part-of-the-application-myself process. People use standard libraries, frameworks, application servers, and most recently, Web services, to build their applications.

The components are getting bigger and bigger and more and more general. These building blocks, which were once looked upon with disbelief and mistrust, are now taken for granted. However, using these general building blocks has a price: performance. We have traded performance for significantly reduced development time and system complexity. At least that's what we think and what our early measurements indicate. What if we're wrong?

Enter Java and JVMs
The beauty of Java from a large-scale application performance perspective is in two features that are very crucial to performance for large-scale systems: type information and a runtime system (the JVM). The type information is needed by the code generator to discern who calls who, and who points to who. As a result more information can be extracted from a Java program than from a C program, if the compiler is smart. The end result is, of course, higher performance. The JVM is the vehicle for dynamic optimization. The JVM can analyze the behavior of the application and adapt itself and the generated code to the application.

The beauty of this runtime optimization approach is that for the first time ever, the whole system can be optimized specifically for how it is used without having the source code. This is the opportunity. The framework developer can build a general framework that gets used by application developers and that gets optimized specifically for each application that uses the framework. The general building blocks are broken down and melt into each other at runtime. It is the responsibility of the JVM to do this melting. The JVMs, including JRockit, have not reached that goal...yet.

When Dynamic Optimization Really Pays Off
Let me give you another example of the benefits of dynamic optimization. Look at Intel's new 64-bit platform, the Itanium Processor. Its characteristics are novel and enticing. Nevertheless, its EPIC architecture puts very high pressure on the compiler. EPIC means that the compiler has to choose which instructions should be executed in parallel. Most normal processors today do that selection automatically in their out-of-order execution engine. Because the EPIC-based CPUs need to make fewer decisions, they increase the computational efficiency. The caveat is that the compiler has to make intelligent decisions for the performance to increase.

Given all this pressure on the compiler, you might think that EPIC architecture is well-suited for static compilation and that it virtually eliminates the need for a dynamic runtime system. I believe we'll be able to show you in the coming years how totally opposite the reality is. The reason is that the devil is in the details: for the compiler to be able to parallelize code in a good way requires more than knowing the instructions of the program. The compiler has to know two more things: the flow of the program, and the values that are passed around and used in different contexts.

A static compiler doesn't have this runtime information; it cannot tell what parts of the program are executed frequently or what values are commonly passed to a function from a specific call site. A dynamic runtime system, e.g., a JVM, is the easiest kind of system to collect and take advantage of such information. Consequently, I expect to see exciting gains during the next two years for the Itanium-based JVMs. There is a possibility that they'll catch up with and supercede the profile-guided C compilers on EPIC platforms. Because it lacks type information and a runtime system, C is inferior to Java for EPIC architecture.

The JVM - The Glue for the Building Blocks
BEA acquired JRockit in February of this year, and we are now working to integrate JRockit into the BEA product line, making sure that it works well with all of the different BEA products. Bringing the building blocks and glue under the same roof makes your system more manageable and scalable and makes it run faster. The JRockit JVM is becoming an important piece of the BEA WebLogic Platform.

In conclusion, I still expect to see a lot of micro-benchmarks out there comparing Java and C programs, but I hope I've convinced you that using runtime systems like Sun Microsystems' HotSpot or BEA WebLogic JRockit Java is not slow or inefficient, and that the performance of a large-scale system built with Java may be superior to that of the same system built using C.