Sun, ARM rewrite the rules for accelerating Java

Sun provided the first public details Wednesday (March 27) of its first-generation Monty, a 150-kbyte virtual machine created by engineers from the company's HotSpot and KVM design teams. Optimized for the ARM instruction set, Monty requires 1 Mbyte of working RAM as a tradeoff for the seven- to tenfold performance boost over the current mobile JVM.

Sun and ARM said Monty is aimed at high-end systems that can afford 1 Mbyte or more of RAM as working space and an unspecified power drain. Systems with less memory or a tighter power budget would use Jazelle, ARM's hardware accelerator, the companies said. Sun will charge an undisclosed amount to Java licensees for Monty and will not provide the software under its open-source contract when it becomes commercially available this summer.

Generational shift

But a bigger shift will come with the next-generation version of Monty, due to ship in mid- to late 2003. Instead of working as an alternative to hardware accelerators like Jazelle, the next-generation software will work in a hybrid hardware/software collaboration with ARM's next-gen Jazelle accelerator core.

Neither company would reveal details of those products, which are now in development. But Nicholas Lorain, senior product manager for wireless Java technologies at Sun, indicated that they could significantly narrow the market for other Java hardware accelerators from a group of largely startup companies, such as Zucotto Wireless Inc., Nazomi Communications and Ajile Systems Inc.

"There will be consolidation in this market," Lorain said. "Right now about 10 companies are trying to provide silicon implementations of Java. Within 18 months this will probably collapse down to two or three getting the brunt of the market share."

A few may find niches by serving OEMs building high-end systems requiring maximum Java performance, Lorain said.

It's not clear whether Monty might also affect the handful of companies providing software-based Java virtual machines and environments. These companies will be able to license Monty, perhaps opening a door to collaboration with chip accelerator companies.

Maybe MIPS

Sun is also in discussions about developing an optimized version of Monty for th e MIPS architecture, which has a significant though small market share, mainly in Japanese-designed phones.

"The ARM architecture probably has 75 percent of the designs with PDAs and cellphones today, and market researchers think it will go to 80 or 85 percent in the next couple years," Lorain said. "MIPS is probably the second most popular architecture here, although it is declining. Some handset makers will continue using MIPS and others won't. There is interest [in a MIPS version of Monty] from some of them."

Excluding ARM, Java chip makers said they knew little or nothing about Monty before Sun presented project details at JavaOne.

"I'm not sure if Monty is compatible with what we are doing or not," said Guillaume Comeau, the chief integration architect for Zucotto Wireless, who first learned of Monty at Wednesday's presentation. Zucotto's chips aim to give a system-wide performance boost to cellular handsets, with Java acceleration one part of that.

Compatibility with Mo nty "sounds like a microcode change," Comeau said. "You need a strong motivation to do that, but if Monty really takes off, that's the motivation."

Ron Stein, senior marketing manager of Nazomi, similarly said his company just learned of Monty at JavaOne. As a byte code processor, the company's part replaces any interpreter or compiler logic in the JVM of a system. For this reason, a system would effectively use either the Nazomi part or Monty, but not both.

Stein said Nazomi has six design wins, two as intellectual property cores and four in the form of standalone chips. However, none of the designs will be announced until midyear, he said.

Sun's plan to charge a fee for Monty breaks with its past practice of seeding the industry with free reference implementations that third parties refine and commercialize. In the midst of a devastating downturn, Sun aims to recoup some badly needed dollars from its extensive work on Java, which has been a strategic plank but also a resource drain requiring significant design efforts and free tools to maintain.

"Monty is not a reference implementation but an optimized product," Lorain said.

Monty revealed

Like Sun's previous HotSpot virtual machine aimed at desktops, Monty employs a dynamic compiler. It runs interpreted code through a profiler which determines which strings might most benefit from compilation to native processor code.

"Dynamic compilation is important because it allows the code downloaded on the fly from the cellular network to run as fast as code resident in the cellphone," said Lars Bak, a senior staff engineer at Sun who led a team of about 20 developers, who worked about a year on Monty.

The single-threaded virtual machine was written in C++, as was HotSpot. Bak said his team will next turn to optimizing the Java libraries associated with the cellphone environment to insure that graphics performance is also tuned for systems using Monty.

To celebrate the unveiling of Mont y at JavaOne, Bak and three other key developers concluded their presentation by dancing onstage while Monty was demonstrated playing back music from the movie The Full Monty, from which the project drew its name.

Pleasing performance

Echoing the sentiments of other handset makers, and of wireless carriers and game developers contacted at JavaOne and the recent Computer Game Developers Conference, Randy Roberts, director of digital convergence for Nokia Mobile Phones, said, "Right now we are extremely happy with our Java performance." The biggest bottlenecks these days for Java-enabled phones are the need for more memory and new methods to deal with the inherent latency of some wireless data networks, the companies said.

"The big issue these days isn't more CPU performance, it's more memory space," said Ernie Cormier, a former design engineer and now vice president of enterprise solutions for carrier Nextel Communications.

"Our biggest issue is that products need more RAM," echoed a spokesman for Sony Ericsson. The company's current high-end smart phones, slated to ship this year, include 12 Mbytes of memory, the spokesman said.

None of the currently announced Java phones use hardware-based Java acceleration. A Motorola spokesman said that company will use ARM's Jazelle acceleration in its 2003 class phones. Nokia and Sony Ericsson spokesmen would only say they are evaluating Java hardware accelerators.

Latency problem

Latency is one little-discussed performance problem for next-generation cellphones gaining significant attention in research labs. General Packet Radio Service (GPRS) networks that typically deliver 20 to 45 kbits/second in data face inherent latencies of up to two seconds on Internet Protocol operations. Latency on wired Internet operations are as little as 200 milliseconds.

The latency issue threatens to make any sort of Web browsing or interactive gaming over GPRS excruciatingly painful. "By the time one player starts a race, the other is already across the finish line," quipped one software developer.

Worse, applications not aware of the GPRS latency factor could time out and crash while waiting for code to download. That's especially significant because carriers deploying the systems expect to recoup their revenues, in part, based on charging for downloaded apps.

AT&T Wireless claims it has developed a utility that converts TCP packets to the UDP protocol, bringing GPRS latency down to 800 milliseconds in best-case scenarios. "We are having ongoing discussions with Microsoft and others on making applications more wireless-savvy," said David Brudnicki, director of emerging technology for AT&T Wireless' mobile multimedia group.