Welcome to JavaSoft(tm) Forum 1.2. We've been very busy since our last Forum on Java Security, and we've felt we owe our readers a provocative and interesting new discussion. This time we're focusing on Java(tm) performance -- a critical issue for developers.
JavaSoft has and will continue to devote enormous resources to optimizing Java performance. Check out the new JDK 1.1, which includes significant performance improvements, especially in AWT. And look for lots more news on performance improvements at JavaOne(sm).
But back to the matter at hand. As in past Forums, we've asked a group of folks for their opinions on our chosen issue. We've assembled those opinions here for your consideration and actively solicit your response. In about two weeks, we'll post JavaSoft Forum 1.2.1, with your feedback and insights.
Our contributors to this issue include John Mitchell, the JavaWorld(tm) tipster; Jeffrey Morgenthal , CTO of the Entropy Group, Michael O'Connell, JavaWorld's founding editor-in-chief; and Dr. Frank Pittelli, Chief Scientist at NetFactory, Inc. Our point of view -- sort of a jumping off point for discussion -- is represented by Miko Matsumura, our Java Evangelist.
Please read, think and write to email@example.com. We'll post your feedback in version 1.2.1.
We look forward to hearing from you.
Miko's point of view on Java Performance:
Java performance has been a critical variable in the adoption of the Java platform. Standardized benchmarks (Pendragon software's CaffeineMark ) that put Java implementations through their paces are beginning to emerge. Other attempts to address speed issues have included hardware level virtual machines such as the PicoJava core designed my Sun Microsystems Electronics division.
There have been several attempts to quantify Java "performance", but it is an elusive subject primarily because of the relativity associated with the word performance. What would provide a comprehensive view of Java performance? In my view, there are five different approaches to accelerating Java:
This includes efforts such as the picoJava(tm) core and other silicon Java technologies, as well as chip-specific Java optimization technology (announced by Intel and Motorola for example) and of course general improvements in chip technology such as the DEC StrongARM-110.
This includes optimization flags within Javac and jvc compilers, JIT technology such as the touted Symantec 2.0 JIT, technologies such as Asymetrix's SuperCede, and compiling Java into native machine instructions. It is postulated that by using dynamic recompilation at run time that Java performance can exceed that of C++.
I'm referring to support for native threading on some systems as well as improvements in garbage collection have resulted in tremendous real-world speed increases for many applications.
Key issues here are significant improvements in JDK 1.1-- most notably AWT performance improvements. (Aside: the much-discussed Microsoft AFCs are a reasonable take on JDK 1.0.2's AWT, but the real comparison should be with the quality of our JDK 1.1 AWT, available today. We've got more now than Microsoft says they'll have in May.)
We're also talking here about functionality that allows processing to be distributed throughout the network -- like Java RMI, also included in JDK 1.1. Distributed processing paradigms allow for virtually unlimited processor scaling on specific applications.
Improvements in profilers and attention to the way code is written can result in many fold increases in Java performance. As programmers gain more expertise in writing Java code, we see a resulting increase in the overall speed of the code written.
JavaSoft and the Java industry have made significant strides in each of these five areas in the last several months, and we think its time to re-evaluate Java performance. Since the marketplace is driving competition between Java implementors and platforms, we'll see improvements at all levels of the performance equation. As each of the layers improves across implementations, we'll see many fold increases in Java performance. And as I said, expect a lot more news on performance at JavaOne.
And now on to the discussion. . . Jeff Morgenthal also added some questions into the mix. He asked our contributors: "What is the greatest performance hurdle for Java to overcome?"
Michael O'Connell responds by saying:
This question no doubt prompts much discussion about speed and efficiency of an app's execution, and I trust many hard-core Java coders will address these issues in great detail. But before readers of this forum -- or JavaSoft engineers -- engross themselves in such discussions and debates, they should consider two more fundamental performance-related questions that may make or break Java's fate as a viable option for corporate and commercial developers: Do they behave properly on all (or at least all major) Java virtual machines? Do Java apps LAUNCH in a timely fashion?
This is a good point, and an important area for a new JavaSoft Forum -- on our Java Compatible and 100% Pure Java programs.
The Java developer community must remember that as a Net-ready language, Java must address the needs of the typical Net-based user. This means we must remember that not everyone constantly is plugged into the net with a state-of-the-art CPU and a T1 line. To become ubiquitous and serve the needs of the average user and the mass market, Java must anticipate modem connections and 486 PCs. With the Net increasingly serving as a software distribution mechanism and with Network Computers (NCs) relying on remote servers for the bulk of their storage needs, it becomes imperative to provide the swiftest and most efficient means of getting software from its idle state on the server to running on the server. If loading time is not improved, runtime performance is moot.
Frank Pittelli jumps in:
The important point is that Java must provide a "consistent" cache mechanism across all platforms, instead of relying on browser vendors to handle caching IN THEIR OWN WAYS. "The JAR format, which batches an app's class files and compresses the resulting file, will help in this regard. However, if the integration of the JAR file and the class loader is not done consistently across platforms and with practical issues in mind, it may not provide the great benefits that everyone expects.
I advocate the creation of a Version-Controlled Cache within the JVM specification, that allows users, developers, and administrators to tailor class caching for their own needs, ACROSS ALL VENDOR IMPLEMENTATIONS.
Performance is a "system" discipline and Java designers should be providing solutions that span the entire system, not just some aspect. Yes, we need compression, archiving, data pushes, etc., but we also need to let users, developers and administrators control when, where and how often classes are loaded in the first place.
Frank delivered a thorough and compelling argument, which we've included separately.
We've also heard from the semi-irreverent JavaWorld tipster John Mitchell:
So what would provide a comprehensive view of Java performance?
Actual and perceived performance of "real" applications by "real" users. i.e., running Corel Office for Java when it's ready for primetime against MS Office and Corel Office for Windows. Everything else has been interesting from a geek standpoint but doesn't do squat for the end users (except frustrate the crap out of them since downloading a bunch of stuff for some "neato" web graphics is lame :-). The key in this are Java applets/applications where users will spend a lot of time using.
John's point of view on the compiler issue. . .
There's a lot that can be done at the compiler, JIT, and run-time level to dramatically increase the speed of Java. One of the issues here is that the theory of optimizing OO code is a lot less well-developed than the optimizations theory and technology for "procedural" code. Projects like VORTEX coming out of UW are trying to remedy that but methinks there is still a ways to go at the theory level. The OO optimization technology used in the current Java products is not even close to the theory (though I don't know squat about the second generation JITs).
When the source compiler, interpeter/JIT, and run-time all work together we'll see performance as good as or better than C++ in many, if not all, areas (because the languages are targeting different areas). Java's relative cleanliness (in a language context) makes for clearer/cleaner/etc. optimization. Dynamic recompilation will definitely open up some big cans of worms but, as has been shown with things like the Synthesis OS kernel, dynamic code generation can produce big wins (especially when we start talking about complex issues dealing with e.g., mulit-threading and synchronization). The drawbacks in a lot of this type of performance improvement is that it makes for a much fatter, more complex run-time system. That starts to preclude using this stuff for heavily constrained environments (e.g., smart phones). For such systems one has to make complex tradeoffs between cost and complexity, battery life, etc. Throwing things like a simpler run-time system that can deal with plain Java but also allows for e.g., Java compiled to native code will likely be necessary.
John's point of view on native threading and garbage collection..
The Sun JDK garbage collector sucks monkeys. There are a lot of very good collectors out there that there is no excuse for Sun not to have fixed this critical problem.
JavaSoft says: But John, tell us how you really feel! We'll invite our engineering team to respond to this assertion in our next rev.
A really tough issue is that of all of the protections checking that take place when running Java code. Yes, the multi-stage loader/verifier/etc. makes things much better than a naive approach there are still significant areas of run-time checking. Things like automatic bounds checking on arrays hammers array processing performance into the ground. Synchronization causes a big performance loss due to contention and poor implementation (though this is supposedly better now than it used to be, I haven't checked and it's still a big issue just less big than before :-). Also, there's a question of the synchronization primitives not providing the "right" primitives to build efficient implementations of the myriad of other synchronization tools (by the way, Doug Lea's Concurrent Programming in Java is an excellent take on this stuff).
And finally, some words from Jeff:
Java performance does seem to be mired in ambiguity. Does Java performance pertain to the speed of bytecode processing, how fast Java code gets compiled into bytecodes, how fast should classes be transmitted over the Internet, or all of the above?
Java performance falls into two main categories -- programming and execution. Key areas where performance will make or break the Java platform include:
1. Applets - When the Web browser is the messenger for delivering Java applets, its implementation becomes Java in a sense.
2. Graphics - There's been much discussion in the past year about whether Java can support heavy duty graphical requirements such as video playback, 2-D and 3-D drawings, and a responsive windowing environment.
3. JavaOS(tm) - Can it deliver sufficient performance to allow multiple productivity applications to operate at the same time. Can it produce a responsive enough environment to write a 500 manual in a word processor inclusive of pictures and tables? Is it just execution speed here, or are there architectural hurdles regarding context switching between applications?
4. Java chips represent a potential method of processing Java bytecodes in silicon. Obviously, the fewer the steps until the instruction meets silicon, the faster the execution of applications will be. Numbers for the picoJava and ultraJava(tm) chips have certainly been impressive, relative to brethren software implementations. However, can just-in-time (JIT) compiler technology provide enough of a performance gain that Java chips become too proprietary of a platform to use in wide-scale deployment? It is probable that the most popular combination will be JIT-ed Java on an Intel platform, simply because of the large base of existing software available. Furthermore, for fairly static applications, newer native code compilers and persistent JIT compilers offer a compile-once scenario that will produce native execution speed on any particular platform offering these options.
Thanks for reading through another JavaSoft Forum. We look forward to hearing from you at firstname.lastname@example.org.
Many thanks to our distinguished contributors:
Miko Matsumura is JavaSoft's Evangelist.
The JavaWorld Tipster, John D. Mitchell, is co-author of Making Sense of Java and the upcoming Dummies 101: Java Programming. He is currently teaching a "Java for Managers" class for an online university and consulting various and sundry firms about 'net technologies and solutions.
Jeffrey P. Morgenthal is Chief Technology Officer of The Entropy Group and editor of "In the Final Analysis. . ." an industry newsletter.
Michael O'Connell is the founding editor-in-chief of JavaWorld, the first monthly magazine dedicated to the Java community. While serving as one of the founding editors for sister magazine SunWorld Online, he wrote many articles about Java. Before launching JavaWorld and helping launch SunWorld Online magazine, he served as Reviews Editor and Editions Editor of Advanced Systems magazine and Editor of Workstation News.
Dr. Frank Pittelli is the Chief Architect of the NetCharts product from NetFactory, Inc. which is a 100% Java-based charting package for both HTML authors and Java programmers. Dr. Pittelli has been using Java almost exclusively since it was first released and has taught Java to more than 250 professional programmers, edited a number of Java books, and presented lectures about Java at numerous conferences.