Java Native Compilation Examined

An Anonymous Coward writes: "DeveloperWorks has an interesting article about compiling Java apps to run as native appplications on the target machine without the need for a JVM."

Well gee *that* makes sense....

[Anonymous Coward]

What's the point of taking a language that jumps through hoops to be "cross-platform" and cutting it's legs off?

Not new ... ho hum

[Evil Pete]

Lets see TowerJ has been out since when ? 1999. Having tried my hand at this I have some reservations. The project I was on ... a large dinosaur of a thing which will remain nameless had 12,000 classes which TowerJ turned into C files which were then compiled by GCC. Resulted in 50 megabyte executables on a Sun. Didn't really solve the problem which wasn't really about speed but throughput. The solution was a better design using servlets and Java Webserver ... result DRAMATICALLY faster without any need for native compilation.

Mind you I noticed in the IBM article that the memory footprint was much smaller. That might be nice.

AWT support a must

[Coulson]

Most notably, there is very little support for AWT, making GCJ unsuitable for GUI applications.

That's the real shame of the matter. Java shines most in its ease-of-use for creating complex GUIs -- unfortunately that's also where the worst memory/performance problems appear. For instance, Swing is good for client apps if you can ship with minimum RAM requirements of 64+ mb (and even that's cutting it close). Performance is most important in the UI, where the user notices any lack of responsiveness. Hopefully some Java native compilers will help out here.

Different compilers support differing levels of class library; Excelsior JET is one compiler that claims to completely support AWT and Swing.

Maybe there's hope yet!

Speed isn't the advantage of GCJ

[Ondo]

The big advantage of GCJ isn't speed, it's the vastly better interface to C++ code (CNI vs. JNI). Of course, using that really does make your code non-portable.

Some thoughts...

[funkhauser]

I always thought Java was very interesting with it's cross-platform compatibility and whatnot. But as everyone has noted, it's painfully slow. I always wondered why people hadn't implemented a native-code compiler for it. Sure, with bounds-checking and garbage collection, natively compiled Java will still be slower than natively compiled C++.

The point is, Java is really just another programming language. What's wrong with allowing developers the opportunity to write their natively compiled software in a solid, object-oriented language that doesn't have all the backwards-compatability issues that C/C++ has?

Whether this will be useful, I dunno. But it opens up options, and that's always a good thing.

Re:It's about time!

[bugg]

Operator overloads make it *way* too easy to write code that is difficult to follow. The ability to add, subtract, etc. objects *rarely* makes perfect sense when you consider everything that the object represents. Really, the lack of operator overloads is not a big deal, perhaps even an advantage, if you ask me. (IMHO)

Another weak study...

[Alea]

I'm not going to try to champion Java, JITs, or native compilation, I'm just going to point out what's wrong with this "study".

This has to be the third or fourth weak study of Java performance I've seen over several years. Issues such as whether or not all Java features are in place in the native compilations (e.g. array bound checking, but note that GCJ turns this on by default) or what sort of optimizations are performed by the native compiler and JVMs are completely ignored. The author also suggests that compiling from bytecode to native code is the natural route when it's quite possible that gains could be made by compiling directly from source to native. While GCJ accepts either Java source or bytecode, it's not clear from the documentation I've read whether or not it first translates source to bytecode or goes straight from source to native.

When comparing disk space, the author comments that an installed JVM can be up to 50 MB vs. 3 MB or so for libgcj. This is a ridiculous comparison since those directories probably include all of the tools, examples and libraries, and as far as I know, libgcj doesn't include the whole J2SE API set, so it's nowhere near a fair comparison. It's a pretty limited set of benchmarks for making these judgements too.

I played around with native compilation of Java a few years ago. At one point (probably around 1996/7?) native compilers could offer noticable gains over Sun's JVM on a numerically intensive application (neural network stuff). However, after the initial versions of HotSpot and IBM's JIT, I couldn't find a native compiler that gave competitive performance on similar apps. I think this is largely due to underdeveloped native compilers with poor optimization (HotSpot is quite insane in its runtime optimizations).

Anyway, I sure hope IBM doesn't pay too generously for studies this poor. Its final message is essentially "who knows?" - not terribly useful.

Alea

My Cynical Take on This:

[DaveWood]

I found it interesting that this author, an IBM researcher, chose to only test a single java-to-native compiler, the GCJ (GNU product). This is an immature open-source package that I would not expect much performance from. His paper rehashes a lot of really basic info, then gives some performance results which show IBM's JVM spanking Sun, Kaffe, and GCJ. This is no great surprise; IBM is tooting it's own horn - fine, they deserve to IMHO. But as an exercise in "the state of native compilation" it's useless. What would actually be really useful is a comparison that also included at least a half-dozen other major players in the java native compiler market. I suspect you'd see some different results.

As an aside; I see people call Java "painfully slow," but in my experience it's not that painful post 1.3. I'm not giving you benchmarks, and anti-Java people will just "no" me, but these are my experiences after a few hundred thousand lines of Java code over the past few years. Anyway, it's a good exercise to ask naysayers what _their_ basis is; they often have none.

Also, as other posters have pointed out, the speed loss must be seen in the runtime safety context, as bounds checking and garbage collection yield stability and security dividends and, at the end of the day, we almost always want those things and are willing to wait the extra few ms for the guarantees.

All these complaints about speed are especially ironic given how many massive wasters there are in the modern computer, _especially_ in Windows NT/2k/XP.

But the biggest flaw in this Java vs. C debate is that often you don't get a choice between writing code in Java vs. C/C++, since you don't have the extra 50% in your time budget to do C/C++, and your real choice is between Java and VBScript...

All the people shouting "I can write C++ 10 times as fast as you can write Java, loser" please form a line in an orderly fashion, you will be spanked in the order you arrive...

Re:Well gee *that* makes sense....

[thomas.galvin]

The point of the article is that if you have a large, slow Java application, you can compile to run natively on a given platform to increase it's speed and reduce the disk and memory requirements

Well, yes and no. There are some very slick Vms out there, and some very lazy compilers, though in most cases, you are correct, native code will execute faster than interpreted code.

The disk requierments, though, can in the long run be larger for native code apps. The VMs have a lot of common tools (i.e. all of the java.* classes) available for any app that needs them. If you plan to compile to native code, you hav to link these in. You can save space by only linking in the libraries you need, but will still end up loosing space when you start installing mulitple applications that all include the SWING packages.

I have been a bog fan of Java for some time, but the need for a VM held me back from a full-out endorsement for some time...it seemed like I was writing toy code because I needed another program to do anything with it, and I didn't like leaving all of those class files laying around. I have gotten over a lot of this, especially once I learned how to make an executable JAR file, and considering the widespread use of DLLs. Plus, I realy like being able to work on my text editor on my home WinXP box, and take it in and use it on our Sun achines.

Still, I'm downloading one of those compilers right now. Why? Because native Java would just be neat. I probably won't even use it that much, but it will be nice to see that it can be done.

Re:It's about time!

[Anonymous Coward]

I would argue that .equals and .plus make code more difficult to follow. The anti-overloading arguement always goes: "Someone will overload operator== to delete files."

But that same person can just call their Java file deletion function .equals().

So the so called 'advantage' is just more marketing bullshit.

And how about the case of a Matrix class? Which is more readable:

Matrix b = a.plus(b.multiply(c));
vs.
Matrix b = a + b * c;

Using template trickery (see Blitz++ for examples) you can even optimize away all the implicit temporaries in the C++ example. With Java, you're stuck both with the less readable code, _AND_ unneeded temporary objects.

I'm the biggest expert here, listen to me!

[trance9]

Lots of experts here.

Some experts who have never used Java want to tell me that it's no good, and will never be any good--why? They don't know, but they know!

And some experts who want to tell me all about why Java's compilation, why it is hard or easy even though they really don't know anything about a compiler.

And some experts on Java's market share who really don't know anything about who uses Java.

And some experts who sat in a room where Java was... gosh gee... being implemented, telling me... well I don't quite know what, but gosh!

So many experts here--I must be reading slashdot!

Re:It's about time!

[gUmbi]

But that same person can just call their Java file deletion function .equals().


Of course they can..and that person would be a goddamn fool.

The point is that an operator overload might make complete sense to the person that programmed it. The next person who looked at it may have used a different convention and interprets it differently.

As an example, I overload (file--) to delete the file. But the convention you read in the latest issue of 'L33T Developer' indicates that (file--) should mean close the file handle. You look at the code, make somes changes and your clients file was just deleted.

And BTW, I would never have called a function that deleted a file .close()

Jason.

Bad review

[Animats]

The simple case, the prime number finding loops, should have been followed by an analysis of the object code to find out why the native compilation is so slow. Look at the inner loop:

• for (long test=2; test < i; test++)
  { if (i%test == 0) { return false; }
  }

If the compiler generates slow code for that, something is very wrong in the compiler.

On the safety front, subscript checking is almost free if done right. Subscript checking can usually be hoisted out of loops. Old studies on Pascal optimization showed that 95% of subscript checks can be optimized out at compile time without loss of safety. GCC, though, being a C compiler at heart, isn't likely to know how to do that. Merely putting a Java front end on it doesn't make it a Java compiler deep inside.

Re:Well gee *that* makes sense....

[NickDoulas]

I agree. I think there are still a ton of benefits to Java without it being interpreted.

It seems to me that most discussions of Java lose track of that fact that the key to the "write once run anywhere" idea is that the Java source code is translated to bytecodes and then executed in a non-ambiguous way. In other words, the language definition doesn't have all the "implementation defined" behavior that C/C++ language definitions have.

It takes a lot of discipline to write truly portable C/C++ source code. It seems a lot easier to achieve this source code portability with Java. I think having bytecode portability is a big plus in some cases but not very important in others.

So there's many ways to execute a given set of byte codes - strict interpretation, JIT compilation, native compilation, etc. This flexibility seems pretty good to me.

Java for servers

[Nick Mitchell]

Java, in the form of EJBs and servlets, is becoming fairly common on "big iron". One reason is indeed the cross-platformability of it. But, frankly, most often a change in platform accompanies a change in framework. For example, a switch from UNIX servers to a mainframe may accompany a switch from CGIs to an application server (such as Websphere [ibm.com]). The dramatic switch here is probably not from UNIX to OS/390 (after all, OS/390 has a POSIX layer), but from CGIs to Websphere. So, as you said, it's not really cross-platformability which is driving Java in the server realm. I think the principal reason is that Java provides (at least some semblance of :) a language-level security model. By security, I don't mean crypto and virii and external attacks. I mean an application is secure from itself, and its (all too human) programmers.

Re:It's about time!

[borgboy]

A common complaint of people writing in a language that lacks feature x is to declare feature x useless or dangerous. Operator overloading makes sense in certain situations, especially where math semantics are being modeled.
Are operator overloads misused? Sure. So are knives, but that doesn't mean that cooks shouldn't use knives.

But you wanna talk about language features that Java lacks? How about enums? Why leave those out? And whats with this whole "bean" concept? Why can't that be a first class concept with real syntactical support instead of this asinine get___ set___ crap?

I could be biased, though.

Excelsior JET

[LadyLucky]

For my own curiosity, I compiled an interpreter I had written in java using this, just to compare the performance.

It took forever to compile, but once it was done, I had a (large) executable for my native platform, windows.

It ran about 30% slower than the JDK. There are a number of things that are still pretty slow in java, but in general, it's a pretty fast language these days. JIT compilers and hotspot to a good job. It can never be as fast as C++ due to things such as GC, but the performance tends to be close for most applications.

This is indeed interesting, but I think it is entirely irrelevant. Speed of execution is usually about 7th on the list of important-stuff-im-thinking-about when choosing a language and starting a project. There are so many more important things, such as maintainability, scalability, code reusability, code robustness (the number of stuff you get so easy compared to C++ just leaves you wondering how you could ever program in C++ again), you know the stuff. These things are often far more of an issue than raw performance. Look at Slashdot, it's written in perl, presumably because they thought it was easier to write the website in, not because it was the fastest thing around.

Re:Java's Cover

[Waffle Iron]

I've never found a language that allowed me to be as productive as Java for the type of applications that I build. The language supports all the things I need such as threads, network communication (RMI) and web development (JSP) and the API allows me to develop apps quickly and with the freedom of interchanging parts (Web servers, databases, etc.) from different vendors whenever I want.

I agree with you relative to C/C++, and I was using Java heavily a couple of years ago. But now I've moved on to higher-level languages such as Perl, Python and Ruby. They each have APIs that provide functionality similar to Java, but usually simpler and more intuitive. They also don't have licensing policies or agendas driven by one particular corporation..

I usually get the same job done with 1/2 or 1/3 the lines of code as with Java. I've also found that once you free your mind from the strong-typing yoke, you can transform your concepts into reality much more efficiently.

It's funny that a few years ago I had to argue to the PHBs that Java was a valid solution. Now, they are set on Java, and I have to argue that a better solution has emerged as support for other languages has matured.

Different tools for different tasks

[Roy Ward]

I've used both C++ and Java extensively (although I haven't used garbage collected C++).

For ease of coding, I find that Java simply outshines C++ because it doesn't leave me dealing with low level stuff, like pointers.

An occasional big time-killer with C++ is trying to debug something that corrupts memory.This doesn't happen with Java (although you can muck up the synchronization with threading and get unpredictable results which is just about as bad).

On the other hand, if I want performance (such as writing image processing software), I'll go with C++ (or assembler), as there is no way that Java can compete on speed for low level stuff.

And even the awful C++ templates are better than no templates at all.

Re:Java's Cover

[FastT]

I think a lot of people hate java because it makes the feel obsolete

I agree. If twisting your brain to think like a silicon chip that is less intelligent than your average paramecium is your yardstick of personal greatness, so be it. It's not mine. I'd rather spend my time defining the architecture to solve the problem at hand than spend a few months writing the infrastructure to support that architecture. I'd rather let an expert on linked lists write the most efficient linked list possible, and just let me inherit from it.

Why does business like it?

For what you said, and so much more. In the end, Java reduces resource costs. It lets them choose their platform, and not be hamstrung because of that decision down the road. It lets them escape vendor lockin. It lets them vastly reduce their support costs. And many other reasons that I'm just too tired to list.

So the last refuge of the C, C++ programmer is speed. They can say there app is slightly faster then Java apps. With computers getting faster every day, this becomes less and less of an argument.

And besides, hardware is cheap, at least to a company. It's cheaper to buy many times more hardware to support a more maintainable application than it is to try to cut hardware costs by spending an arm and a leg developing the fastest, most efficient software. Not only do they risk not doing that (it's like a 10% shot that they can even do it), but the lifetime of hardware is much shorter than that of software, and it tends to be a fixed cost, unlike problems with software.

Re:Well gee *that* makes sense....

[MisterBlister]

Try rereading my message.

What you do in that case is pull the source code out of source control and recompile for the new platform.

100% source code compatibility between platforms is insanely useful. 100% binary code compatibility between platforms, while nice, is not nearly as big of a deal for most systems... As long as you can easily recompile the original source and it runs the same, why not go for the extra efficienty of native if you dont need things like extensive runtime typing (reflection, etc)?

Re:My Cynical Take on This:

[myelin42]

I know I'll get flamed for this, but ...

If you want to use templates as well as garbage collection, you might like Managed C++ [gotdotnet.com], the .NET version of C++.

It'll let you code in C++ (with templates etc) but also use garbage collected arrays etc, and the .NET class library [microsoft.com].

100% right!

[GCP]

Sun pushed *binary* compatibility so hard because Java's claim to fame was taking what loaded into your browser from static content to full executable apps -- making the underlying OS irrelevant in the process. "Death to Windows!"

It didn't work out. Client side Java is essentially dead. "Death to Java applets!" C#/.Net will become what Java only dreamed it could be -- but, sadly, only on Windows.

In the meantime, Java hit pay dirt on the server, because the language is so easy and productive to work in and the result is so portable.

Source portability would have been sufficient on the server, though. I can't prove it, but I strongly suspect they could have created a better server-side programming language if they had designed for 100% *source* portability, then instead of constraining themselves to binary portability and security sufficient for running *anybody's* binaries on *anybody's* client, had instead optimized for high performance plus ease of rapid, bug-free development -- more like Eiffel.

Re:My Cynical Take on This:

[FastT]

The difference is that FORTRAN and COBOL are not even in this race while Java is right there trying to compete with C++.

That's an interesing point. It's certainly the perception, anyway. You can't write an OS or device driver in Java, but you can in C/C++. You can write an application in C++, but should you? It used to be that C++ was the only game in town for application development. It's what programmers knew, and the APIs they needed from the OS were written in the same language. It's great for writing low-level things, or things that need absolute speed, but it certainly doesn't excel over other languages for building apps, especially networked apps. Delphi/Pascal, VB, and Java are all better choices there. Why that's a problem for some people, I don't know.

Actually I do know. Whatever tool someone last used is what they consider the best tool for the job, especially when they don't have experience with lots of different tools. It takes intellectual honesty to admit that your favorite tool isn't always the best tool for the job, and it takes a fair amount of experience and detachment to reach that point.

Reflection

[rob_ert]

Nice, but what about reflection??

lies, damn lies, and benchmarks

[fish waffle]

Some points elided over in the article:

• Memory footprint can be a major factor. Very nice that one program performs better than another given infinite memory (340M---large enough anyway). My computer, however, has considerably less memory, and most other people i know have 64M--128M; moreover, there are often several applications/processes competing for that memory. How well would these VM/compilers work on IBM's own netvistas, standard with 128M? How about with a benchmark that actually needs significant memory (as opposed to a prime sieve, which has minimal memory req.)? Once you start to run low on memory, things slow down dramatically, and once you start swapping you have 0 performance---i do not believe their results reflect a realistic usage scenario.
• Tiny, micro-loop benchmarks are of little value for most java users. Programs that spend the majority of their time in a few small, simple loops are extremely sensitive to the exact optimizations performed---depending on the exact instruction sequence, branching setup, cache layout etc your otherwise great compiler may look like crap, or vice versa. If your program consists of a few very tight loops then these results are meaningful; for the other (100-e)% of java users, it's of minimal value
• Their benchmarks do not test the features people rely on most---how much garbage collection does scimark really require? How many string operations, virtual function calls etc?
• In a small benchmark it is just far too easy to identify (off-line) the few APIs called, and then make sure your VM/compiler spends disproportionate effort optimizing those apis. These are programs with trivial hot-spots; locating such bottlenecks in a real application is difficult for many reasons, so again these results do not transfer well
• When do they start measuring time? It looks fair, using the java code itself, but there are subtleties. My user experience with an application begins when i press enter on the command line (or click on an icon); for the native app it has to load its libraries etc. The interpretted version has to load all the vm libraries, and start compiling the startup code. There's a lot of work done before it ever gets to the currentTimeMills() call---i do not see this accounted for anywhere. Further, their results are 'average of 3'---are these 3 runs after 3 cold boots, or 3 runs seeing how much the cache still holds?
• Their "pros and cons of native compilers" section is much heavier on the cons then the pros. They ignore packaging simplicity (a single executable or one with a few dlls might be easier to give to a customer than an entire vm), interaction with other applications (uh oh, user installed jdk1.3 but we need 1.4, and that other app needs 1.2, ...), security (already mentioned by others here, it's a fair bit harder to decompile binaries than bytecode).
• I'm astounded they list VAJ in their resources section for native compilers. VAJ used to contain HPJ, but it hasn't been there since java went to version 1.2.

I expected a little better from their 'developerworks' people---this is just marketing drivel.

Re:Well gee *that* makes sense....

[Anonymous Coward]

Not to mention that most platforms feature some sort of dynamically-linked libraries, so you could still reap the benefits of a single core Java installation, while (hopefully) improving execution time.

A native-code compiler doesn't make Java any less portable. In a broad sense, it just lets the JVM do its work once, instead of repeating the same work every time a program is run. .class files would still be meaningful, both as a means of distribution, and to support applications such as Applets that actually need to be platform agnostic.

I read a similar article in Byte magazine 5 years ago (give or take). It was a good idea then, its a good idea now.

JVM bloat

[Everyman]

I know this discussion isn't about Java applets running in Web browsers, but there are plenty of comments about the bloated JVM. Therefore, I'd like to add my two cents about the situation I've experienced on my website that uses an applet I wrote.

I use the applet because I have a unique, interactive GUI page that needs to address the screen pixel-by-pixel, and Java applets are the only game in town if you want the maximum number of different browsers to be able to run it.

The applet is written for Java 1.1, which is the level of built-in Java support for all Explorer browsers (80 percent of the market) and all Netscape through 4.X (another 10 percent).

My applet works smoothly with these browsers, mainly because the JVM is built into the browser, and the 1.1 level of support makes the JVM package much, much smaller.

What concerns me is that with Opera (starting with ver. 6.0), and Explorer 6.0 (if you download Sun's JVM plug-in instead of the MS download), and other browsers that refer you to Sun for Java plug-in support, I have a problem. The integration is poor between the browser and the JVM, when Sun's bloated 1.3 is used instead of a stripped-down, built-in 1.1 of yesteryear.

There are two different areas that are problematic, and they make my application unsatisfactory. One is that the JVM 1.3 is so utterly bloated that the load time for the plug-in is objectionable. The other is that on several different browsers I've tried using the 1.3 plug-in, the browser and the applet don't always know which one is supposed to be in control. The communication between them, or the integration of one with the other, is so poor that the browser is likely to hang. For example, clicking on a link from inside the applet, when that link points to a page with another applet, will often spell trouble.

I think that Java has become so bloated that Sun is inadvertently forgetting about the use of applets on the Web.

Too bad, because you know who will step into the vacuum.