Does Java Need More Caffeine?
If language is the upside of Java, performance is the downside--both actual performance and the end user's perception of performance.

"Java is slow," says Jim Turley, senior editor of Microprocessor Report. "It's stack-oriented. It's slow. It's memory-hungry. It's slow. It's interpreted. It's not clear to me which among those features engineers are begging for."

Turley, whose Microprocessor Forum is often the launch pad for new chips, isn't convinced performance will improve even if Sun eventually fulfills its much delayed promise of Java chips. Putting Java on silicon is extremely difficult and there isn't a huge demand, he says. In addition, while chips will reduce memory requirements, Turley says there's no evidence that they will put Java performance on a par with C++.

Turley predicts that chip manufacturers, including Sun, NEC, Mitsubishi Electronics, Samsung Electronics and Rockwell International Corp., will produce a Java chip for a single platform just to say they've done so. He doesn't expect to see any of these Java-based chips--likely to be priced around $50--until year's end, at the earliest. Licensees of Sun's picoJava chip architecture include IBM Corp., LG Semicon, Fujitsu, Rockwell, NEC and Siemens Semiconductor (for use in smartcards).

A more reasonable option than chips for increasing performance, says Turley, is JIT (Just-In-Time) compilers, which can bring Java performance to within 80 percent of that achieved by C++ applications.

Not everyone agrees with Turley, however. Microsoft executives envision Java performance eventually coming within 10 percent to 15 percent of C++. And early tests of JVMs (Java Virtual Machines) based on Sun's JDK 1.2 (Java Development Kit) show promise of performance improvements. The JDK 1.2 relies on Symantec's JIT and provides a foundation to plug in Sun's HotSpot virtual machine accelerator. It includes performance enhancements and is slated to appear in November, but HotSpot has been bumped until the first quarter of next year.

John Neffenger, CTO and founder of chat software provider Volano, says benchmarking tools he developed for Java show that JVMs emerging by year's end provide performance comparable to native code for classic server-side networking--especially when other bottlenecks on the Internet are considered (see www. volano.com). Prerelease JVMs from Microsoft, Novell and JavaSoft--along with an older JVM from IBM--all were capable of handling 1,200 messages per second or more in testing, according to Neffenger.

Neffenger says JVM performance has increased by more than 30 times over the past three years, with SunSoft boosting its JVM tenfold in a matter of months--something "you don't see in C, ever." He also points out that performance is influenced by how well code is written, and many programmers are still learning Java.

The best performance in Neffenger's testing was turned in by Tower Technology's TowerJ JVM, which handled more than 1,700 messages per second. What distinguishes TowerJ (aside from the fact that it isn't free) also scares many believers in the Sun vision: TowerJ derives its speed from native code compilation, which can affect Java's portability. Microsoft officials, as well as many analysts, are convinced that performance, especially on the server, is so important that native compilers are inevitable--even if they reduce portability. IBM's VisualAge for Java, for example, can be used to provide native compilation for IBM servers.

While native compilation can occur without influencing portability--if the code is distributed in bytecode or source code and the compiler uses platform-specific code--Neffenger says compilers are fairly new and most don't seem to be used this way. He points out that this tends to be more of an issue on the client because businesses frequently know what platform they'll use for the server and optimize for that platform. He also thinks compilers "may be the only hope for Linux and BSD," which fare poorly in his JVM performance testing. Sun's official line, however, is that JIT and other performance enhancements will suffice without resorting to native compilers.

So, how fast is fast enough? Gartner Group concludes that performance is relative and that Java performs adequately for network communications, embedded code, compilation of Java bytecode to native machine code, JIT compilation, data access, interface code and simple business applications on a VM. Gartner says it finds Java lacking in performance when it comes to applet download, system-level code, floating-point math calculation, garbage collection and Java chips. By 2001, Gartner says it expects Java to be adequate in each of these categories, with the single exception of applet downloads. Gartner predicts by 2001 Java performance will cease to be a major barrier to Java adoption in more than 95 percent of cases.

Scalability, however, enters as a related issue. Neffenger is convinced that performance is last year's Java issue. He finds Sun's JVM to be "super stable" and Microsoft's to be "super fast," and he predicts that it will be about a year before performance, scalability and reliability will reach the point that making a JVM choice will be "trivial and random." The three most scalable JVMs that also maintained performance in Neffenger's new scalability VolanoMark benchmark are JVMs expected to ship this year from Novell, Microsoft and JavaSoft. Each could handle 900 messages per second with up to 900 connections. Each 60-character message is broadcast to other clients in a group and then discarded.

Neffenger is personally trying to push Sun to move away from a one-thread-per-client model in Java, which makes programming easier but decreases processing efficiency as the number of connections rises. He concedes, however, that this problem goes away once distributed objects are used--something he plans to tap into with the company's VolanoChat software by year's end. With distribution, he thinks the number of concurrent connections to a Java server application can scale up to 10,000 or more on a single machine. Without using distributed objects, he suggests that 2,000 simultaneous connections is probably the maximum for a single 100 percent pure Java server process, and 1,000 is more realistic. Neffenger submitted his benchmark software to the SPEC server-side Java benchmark group (www.spec.org), which plans to release a benchmark suite next year. The recently released SPECjvm98 is a client-side benchmark from a consortium of universities and vendors.