Volume Number: 13 (1997)
Issue Number: 9
Column Tag: From The Factory Floor

A CodeWarrior Java Update

by Dave Mark, ©1997 by Metrowerks, Inc., all rights reserved.

Tim Freehill is the Engineering Manager for the Java Tools team, with technical responsibilities for the compiler, linker and preference panel plugins. He also concentrates on developing his pointy hair style.

Greg Bolsinga writes Class Wrangler, worked on porting the 1.1.1 javac compiler, and enjoys relieving the TX heat at the local swimming holes while not coding. He is a Scorpio, and his favorite color is purple.

Clinton Popetz just can't keep his hands out of the Java pot, and has the burns to prove it. When not engaged in mind-meld with his Mac, he is a typical slap-happy father of two, and a practioner of Kuk Sool Won, a martial art in which he serves as a chew toy for evil black belts.

Scott Kovatch is a software engineer who lives in Round Rock, Texas with his wife Sandy, and their two cats Star and Shadow. He has been working on Macintosh applications for five years, and is currently working on the native implementations for the Metrowerks 1.1 Java virtual machine and Metrowerks Java.

Kevin Buettner is the JIT compiler lead. He concentrates on the overall JIT architecture, performance enhancements, and the PowerPC code generator.

Laurent Visconti is a "virtual" Metrowerks engineer living in Boston. He spans the bridge between the Java and compiler groups at Metrowerks while working on the Java bytecode compiler and the Java to native compiler.

It's hard to believe, but it was just last year that Java first made its appearance on the Mac. Since then, lots has changed. This month's interview is with the Metrowerks Java team. Read on to learn what's coming down the pike in CodeWarrior Java...

Dave: What Java related technologies is Metrowerks working on these days?

Tim: CodeWarrior Java has seen a lot of extra attention recently, and we've really put a lot of work into streamlining the tools and expanding the Java support within CodeWarrior. We are making CodeWarrior work better as a Java development environment, and we're adding new functionality in several areas.

For example, we are working on our ability to compile Java source directly into machine code, leveraging our existing compiler backend technologies to produce quality Java to native code for a variety of platforms. We'll also have a new backend which uses our optimization technology to produce highly optimized bytecodes. Our ClassWrangler tool is growing by leaps and bounds, giving developers a more sophisticated mechanism for exploring their class libraries. Constructor for Java will be growing into a full Rapid Application Development tool for Java and will be fully integrated into the IDE. Lastly, our VM has received perhaps the most attention, giving us current JDK compatibility and undergoing many, many optimizations for speed, both in the core VM and in the JIT.

Dave: What's the story with the CodeWarrior Java to Native compiler? Will it be compatible with the various CW Back-ends?

Laurent: The Java front-end will generate the standard CodeWarrior IR (Intermediate Representation) that is used by all the CW back-ends. Therefore the Java compiler will be able to invoke any existing or future CW back-end. Because of this architecture developers will be able to generate native binaries with no need for a JIT or an interpreter. This architecture also enables the various optimizations performed both at the IR level and in the back-ends. This will allow the generation of binary code from Java sources equivalent in quality to code generated from C/C++ sources.

Dave: And the new Java back-end?

Laurent: We will implement a new Java back-end that will translate IR to Javabytecode. Because of the optimizations performed on the IR, this new back-end will allow developers to generate better optimized bytecodes.

Tim: This is the same optimization technology CodeWarrior uses in some of its other compilers, so it's proven. It will make even the interpreted bytecodes run more quickly, even without a JIT; with a JIT in place, the code runs that much faster. Also, size optimization can make applet class files download more quickly.

Dave: What's new with Class Wrangler?

Greg: First, Class Wrangler is a program that will allow Mac users to create zipfiles and examine zip files, with an emphasis on zip archive files for Java. You can view all the classes in your archive, and add and remove classes from the archive. As Java programmers already know, it's really easy to get class files with file names longer than the Mac's limit of 31 characters.

When you drop a class file onto Class Wrangler, it will examine the actual class data to determine what the class really should be called in the zip archive. Class files keep lots of data about themselves in their object code. In the Information window, you can see all the methods, all the data members, the super class, all the interfaces, the source file, and the package of a class. You can copy the java code or the java signature to the clipboard, which really comes in handy for native method calls, both Java->native and native->Java.

Class Wrangler is also ready for JDK 1.1's JAR files. It will read and write compressed JAR files. We will be expanding ClassWrangler's JAR capability to handle java digital signatures and other security features. Soon we'll also add the ability to put any type of file within the zip file's hierarchy. This way users can create an images directory for their gifs for JDK 1.1, all within a single JAR file. Class Wrangler is a simple utility for Mac Java programmers, but it's handy for all Java programmers. It will be on Windows soon.

Dave: What class libraries will CodeWarrior support?

Tim: Java frameworks are moving towards the component model, which is great for RAD. By using a defined component API, such as Java Beans, we will be able to support a variety of frameworks. The tool need only know the component API. It can query the component, and the user can put them together in a meaningful fashion. This allows our users to choose what framework they want to use, and lets us remain agnostic about whose framework we support.

Dave: Constructor for Java has been final or some time now. Can you tell me about the next generation RAD tools as they relate to Java?

Clint: The preferred mechanism for RAD in Java is quickly becoming Java Beans. Beans provides a simple metadata infrastructure for component software, and this makes it very attractive to RAD tool designers. In the past, developers created their own proprietary scheme for managing processes such as reanimation, event hookup, component introspection, description, and packaging. Beans provides a common API for these pieces, and provides it in a framework independent fashion. Currently, the Java framework landscape is diverse and confusing. But by building our Java RAD plans on Beans, our work can go forward as the framework wars are waged, without fear of obsoletion.

Dave: What VMs will CodeWarrior support? Apple MRJ? Sun JDK VM for Mac? Microsoft VM?

Scott: Well, there are a couple of levels of 'support'. The first is bytecode support -- our Java compiler generates bytecode that will work with any Java VM, whether it's on Windows, Mac, Unix, or any other platform. Then there is run support, which means "What can CodeWarrior tell to run your Java code?" This one's pretty broad as well -- just about any Java-enabled browser, Metrowerks Java, or Sun's applet viewer can be used to run your Java code directly from CodeWarrior.

Finally, there is debugging support, which means "VM's that our debugger can talk to". Our long term plan is for our debugger to support any VM that implements Sun's debug API, and right now, that means the Metrowerks VM and Apple's MRJ. Obviously, the more VMs we support, the more solid your VM testing can be.We understand how important that is. Bottom line, we need to be VM-neutral, but we do play better with some VM's than others.

Dave: Can you talk about the direction of the CW VM?

Scott: I guess the best way to describe the VM's direction is that we don't intend the Metrowerks VM to be the reference standard for Java on the MacOS -- it's up to Apple to do that as it moves Java into the OS. But until that day happens, we'll do everything we can to provide developers with the best tools for Java development. That means making sure that our VM keeps up with enhancements defined by Sun, and providing the additional tools that come along with those VM enhancements. To that end, we've updated the VM, compiler, and Metrowerks Java to version 1.1.x, which should have shipped in final form by the time you read this. (Sun seems to put out .x versions every other week, so who knows where we'll be when this article prints!)

In addition to the 1.1 features you would expect, the 1.1 VM will support a number of APIs that can be used to embed the VM into a developer's application. Apple's JManager API is supported, as well as Sun's JNI and Microsoft's COM.Many people have asked us if we're going to support JRI (Netscape's native interface API). When we wrote the VM for Internet Explorer, there wasn't a need for JRI, so we didn't implement it. But now that Sun's JNI is becoming the standard for a native interface to the VM, and the fact that JNI support is basically cross platform, we decided that we will support JNI in the 1.1 VM. I expect that Apple will move from JRI to JNI as well given that JRI is generally going away, so it looks like our decision was a good one.

We've also added some new features to Metrowerks Java to make it more useful as a Java development tool -- things like a basic JAR file maker, being able to print the console window, more flexible tool dialogs, and the ability to choose which VM you want to work with. As I write this, we're still sorting out what will or won't be included, so there may be more than that, but I can say these will be there.

Dave: What are you doing to improve JIT performance?

Tim: Enhancement of our JIT technology is bringing an enormous speed boost to our VM's performance. We have engineers that are dedicated to optimizing our core JIT technology, and this is really having tangible effects. Between CW11 and CWPro1, our benchmark scores doubled. We expect this trend to continue, as we add more and more optimzations to our JIT.

Kevin: With respect to the JIT, there are two types of optimizations which can be done. The first concerns improvements in code quality, i.e, making the JIT compiler produce code which is more optimal in some way. The second is concerned with making the translator (JIT) itself faster or more space efficient.

Our recent efforts have been towards improving code quality, sometimes at the expense of translator speed. As Tim mentioned, we've seen a tremendous improvement in some of our benchmark scores. This is due to an optimization step which we've added which performs transformations on the internal representation of a method. One example of the type of optimization that we've done is to look for patterns which represent the logical not operator in java. Since there is no java bytecode which represents the logical not, a java compiler is forced to compile something like the following java statement:

cond = !cond;

into the following java bytecodes:

0 iload_0
1 ifeq 8
4 iconst_0
5 goto 9
8 iconst_1
9 istore_0

Note that there are two branch instructions. If we were to naively transform this to native code, we'd also end up with a test and two branch instructions. But on most processors we can do considerably better. What we did is to invent a new instruction called "lnot". Our optimizer recognizes patterns like the above and transforms these patterns to our new "lnot" instruction. Remember that this new instruction is a new instruction in our internal form, not some new bytecode we've added. But if we were to code it as bytecodes, the above would look something like this:

0 iload_0
1 lnot
2 istore_0

Of course there are many other optimizations that we do, but most of them are similar to the one described above where we look for certain types of patterns and then perform the obvious transformation. Our future efforts will be to do more of the same and also some tuning of the JIT compiler itself so that it will do its translation in a shorter amount of time.