The machines are virtual, but the issues are real -- ADTmag

The machines are virtual, but the issues are real

By George Lawton
June 25, 2001

The Java programming language has been designed to provide a means of writing object-oriented applications across a wide range of platforms. The Java Virtual Machine (JVM) plays a key role in this write-once, run-anywhere concept by providing a range of similar functionality on virtual computers across multiple computing platforms. Software developers save their programs as Java byte code, which is typically interpreted in near real time by a just-in-time (JIT) compiler. While the promise is bold, there are questions as to what level of cross-platform compatibility and robustness is now being achieved by enterprise applications.

"The primary value [in Java] was not about the Web browser and the Internet, it was about creating software that is hardware agnostic," said Simon Phipps, program manager for IBM's Java Technology Center in Hursley, United Kingdom. "The basic value was to have a JVM that could be embedded in all of our OS products so we could use a common base of software throughout our product range. It is a statement that most of the costs of owning a computer system come with looking after the software you have installed."

Java gave IBM the ability to decouple the software from the machine and operating system, potentially freeing IBM from relying on Microsoft for the operating system. "One of the reasons we did this," Phipps noted, "was because of the growing dominance of Microsoft. The JVM is all about providing a safe place on a PDA [Personal Digital Assistant] up to a mainframe where a computer program can run without the need for support on the PC. I envision a world in which business solutions are delivered to employee desktops rather than written in Windows or OS/2. To make that world come about we needed to have a JVM."

Ensuring JVM cross-platform compatibility

ut some wonder if this write-once, run-anywhere vision can fully play out. For example, Craig Ross, a Buffalo Grove, Ill.-based analyst for the Meta Group, noted, "That is obviously a little suspicious when you look at the number of JVMs on just the Windows platform." It is worthwhile to talk with the engineers doing the virtual machine porting in order to get a better view on virtual machine progress.

Clearly, the biggest rift is between Microsoft and Sun Microsystems at the moment. This rift will continue to grow thanks to divergent goals: Microsoft wants to sell more Windows, and Sun wants to sell more Unix. Ross said that the last time there was a lowest common denominator between JVMs was in Version 1.1, when Sun proposed Remote Method Invocation and the Java Native Interface for passing calls between programs and the operating system. Microsoft preferred to use its existing Windows Foundation Classes instead.

Klaus Krull, senior product manager for JBuilder at Inprise Corp. (formerly Borland International Inc.), Scotts Valley, Calif., echoed the sentiments of many when he said, "Microsoft is trying to co-op Java to have its own version of the VM that is tied to the Windows platform. Their position is having the best virtual machine for Windows, and they will discard any cross-platform issues. For example, Microsoft is adding some key words to the language itself."

This lack of cross-platform compatibility affects primarily those employing the visual development interfaces of Microsoft's Visual J++. Alex Morrow, a fellow with the Internet Applications Division of Lotus Development Corp., Cambridge, Mass., said that it is possible to write cross-platform-compatible Java applications using Visual J++, providing one codes the program as opposed to dragging and dropping programming icons into place.

To protect its Java property, Sun has sued Microsoft. But Meta's Ross does not believe that litigation will alter the compatibility issue. "The licensing issue," he explained, "revolves around issues of logo, which don't really matter to Microsoft. They have already called it J++. They are not calling it Java on the box."

Sun is licensing the source code for the JVM and provides this to companies to help them develop their own implementation, along with the Java coffee cup logo. Microsoft has made an agreement for early versions of the source code to get started, but is doing the development of newer versions based on the specification.

"Microsoft will not get the coffee cup logo, but if there is any company around that can survive without that kind of assistance, it is Microsoft," Ross noted. "They have enough resources to make it work."

Microsoft is not the only company developing independent or "clean room" versions of Java based on public specifications. The practice is gaining steam, particularly in the embedded systems arena where clean room JVM implementations have emerged from Hewlett-Packard (HP) Co., Cupertino, Calif., NewMonics, Ames, Iowa, and NSI in Israel.

On separate occasions in public forums, Sun's chief operating officer, Ed Zander, has said that Sun supports these efforts provided companies do not create subsets of Java. But Chris Schoppa, chief architect for HP's embedded software operation, believes that subsetting Java is the only way to ensure that it will fit the needs of dedicated devices, such as business terminals, printers and medical equipment. "For cost reasons, you only want to support enough application runtime to support the use model of that device," he said. "Sun needs to break the specification into more parts. You want to have a good platform definition."

Another compatibility issue with Java revolves around the vast number of old JVMs that are still running on people's desktops. "If a large organization does not have good software distribution, there is not an easy way to make sure that everyone is on Version 1.2 when you have 2,000 desktops," said Meta's Ross.

While programmers continue to acquire the latest programming tools and to program to the latest browser specs, many users are happy surfing around with their older Web browser, which can potentially lead to Java applet crashes. To alleviate this problem, Sun has released the Java Plug-In, a virtual machine that plugs into any browser. "This is probably more of a solution for intranets than the Internet since most people will not want to download a JVM over the wire," noted Inprise's Krull. Inprise has developed the Deployment Server for

Java to address JVM update issues within the corporation. The server can automatically update users in a corporation with the latest JVM if they are attempting to execute a newer application.

Improving Java performance

Performance has always been an important issue for Java. The first implementations of the VM ran Java programs as slow as one-thirtieth the speed of equivalent C++ programs. Sun's rapid series of updates from Version 1.11 up to 1.16 were introduced to optimize the library, improve parts of the runtime infrastructure and improve reliability, said Tim Lindholm, a distinguished engineer at the Java Division of Sun Microsystems.

Phipps at IBM has also seen a dramatic increase in the performance of Java. "Java has gone from being 1/30th the speed of C++ to being less than half the speed," he noted.

There are several primary approaches to optimizing the JVM, including tweaking garbage collection and the JIT compiler. Unfortunately, there is no straight-line path to optimizing Java across all platforms. It is a process that must be pursued extensively on each target platform.

"I discovered long ago that, with different implementations of the same idea, you are always involved in doing a concept mapping," explained Phipps. "One of the things we discovered in porting Java is that the JVM depends on a particular world view on how garbage is collected and memory management actually works. With the first port, you find that things run like a dog because the conceptual mapping from Java is so different. You find the concepts that are farthest apart, and then find the ideal mapping for them."

One of the greatest improvements to Java may come from a new implementation of the JVM that uses a number of novel technologies. The most important aspect is that it focuses its optimizations where they will have the biggest impact, instead of trying to optimize the whole program equally well. "We find that 90% of the execution time goes into 10% of the code," said Sun's Lindholm.

This is the thinking behind Sun's HotSpot compiler optimization technology. This software is said to be capable of learning as it executes new applets and applications. HotSpot is able to identify things going on in the program that previous JIT compilers could not see.

Said Lindholm, "Java method invocations are often virtual, and you cannot know what the object invocation will be targeted for. HotSpot makes predictions about how things will go based on the past. HotSpot can do a speculative optimization and then back out if the optimization does not prove effective later on. JITs don't have the infrastructure to learn about programs."

Running on top of garbage

Memory must be continually recovered when applications stop using it or the machine will eventually run out of memory and crash. But there are a number of divergent ways of doing this. "If you do any delving into the academic domain, you will understand that there are as many opinions about garbage collection as there are people in the market implementing it," IBM's Phipps noted.

Phipps said that in the early days of Java, his team ran into the problem of deciding what was garbage and what was data. "That led to behavior that looked like memory leaks," he said. "Undoubtedly, there were some memory leaks, but most of the things that looked like memory leaks were the garbage collectors being conservative."

Sun's upcoming HotSpot technology employs a new type of generational algorithm that takes advantage of the fact that most memory usage is short-lived, while a smaller subset is used over a much longer time frame. The so-called "Eden space" in HotSpot -- an area in which new objects are born -- does some extra bookkeeping. At regular intervals, the garbage collector cleans the Eden space, and the objects that survive the collection may be moved into an older space. This approach allows garbage collection to happen more frequently and more quickly because the collector does not need to examine the older objects that are more likely to be still in use.

Speeding things the old-fashioned way: Precompiling

The problem with JIT compilers in general is that they have a limited amount of time to optimize an application. The longer they take to optimize, the longer it is until the program can start to run. Another approach is to precompile the Java code for the target platform, which gives the compiler time to do complex global optimizations.

This approach makes the most sense when you can be sure of your target platform, such as when deploying a server application. TowerJ from Tower Technology, Austin, Texas, was an early provider of a consistent cross-platform execution environment for running precompiled code onto Java-enabled servers.

"We call it write-once, compile-anywhere," said Robert Howard, chief technology officer at Tower.

The most impressive thing about TowerJ is its claimed relative performance increase of two to 10 times vs. other JVMs running on the same servers. "This is an important story for ISVs that want to get better performance and reduce the support burden," said Howard. "For individual companies, the question is how logic-intense their application is. The more it requires in terms of resources on the server, the better value that TowerJ is."

The road ahead

Java seems to be proving its capabilities and is in a position to enable a new era of software usage and distribution. But this will require coordination between software developers and JVM creators. As Lotus' Morrow noted, "The crucial thing at this point is that the ISVs are engaging developers to create the JVMs to feed back to them so that we can constantly improve the breed. The basic idea is sound. Now the question is how do we tune it up and take the bugs out?"

Morrow believes that what is needed is a large base of working applications that can be used as a test suite to evaluate the performance and compatibility of new JVM implementations. "At this point, we need to create a test suite for the evolution of Java. When people shipped DOS in the early days, they had 3,000 DOS applications they would test to make sure it was DOS," he said. "We need that large number of apps we can run against Java. The next phase is to create a whole bunch of applications written against the current interface."