Sep 97 Factory Floor
Volume Number: 13
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.