Slashdot Log In
Java Native Compilation Examined
Posted by
michael
on Wed Jan 30, 2002 09:05 PM
from the just-in-time dept.
from the just-in-time dept.
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."
This discussion has been archived.
No new comments can be posted.
Java Native Compilation Examined
|
Log In/Create an Account
| Top
| 486 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Re:Well gee *that* makes sense.... (Score:4, Insightful)
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:Well gee *that* makes sense.... (Score:5, Informative)
Further, not everyone even cares about the cross-platform nature of Java to begin with. I've worked on a few projects where the OS requirements were completely fixed but Java was chosen anyway -- for its rapid-design features (built-in garbage collector, nice network access classes, etc) rather than its cross-platform nature.
All in all, its good to have a choice..Just because you can native-compile Java doesn't mean you have to do it.. And in situations where cross-platform is not needed, why not compile to native and get the extra efficiency? Choice is good.
Its a shame Sun spreads so much FUD about native-compiled Java.
Re:Java for servers (Score:4, Interesting)
I agree with your points, mostly. The company I work for has a TON of function implemented on Websphere running on AIX. We really haven't cared too much about cross-platform features (do a bit of sharing between NT PC apps and Websphere AIX). We were an early adopter of Java because it seemed to address a lot of issues we had in developing C++ and Smalltalk apps (e.g. packaging, garbage collection, change mgmt, etc.).
However, we are planning to move our Websphere AIX implementation (for EJBs anyways) to an IBM390 box (or Z Series these days I guess) and we've found the proof-of-concept effort easier than we anticipated - simply because we can pickup our code (in JARs) and run it on big iron. Very nice! It also gives us some encouragement that we can really start to share more Java classes/components between browser-delivery and fat-client environments if we're smart about it.
Anyways, just one experience that's worked out...
Re:Well gee *that* makes sense.... (Score:4, Informative)
I do most of my development on a Windows box, and deploy to Solaris and Linux. It's been years since I've seen a bug only manifest on one of the three systems.
100% right! (Score:4, Insightful)
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.
What about Java's safety advantages? (Score:3, Interesting)
Not new ... ho hum (Score:5, Insightful)
Mind you I noticed in the IBM article that the memory footprint was much smaller. That might be nice.
AWT support a must (Score:5, Insightful)
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!
Re:AWT support a must (Score:4, Informative)
Benchmarks (Score:3, Interesting)
Speed improvements very noticeable in PDAs (Score:5, Informative)
and also http://www.superwaba.org for info on the related JVM for PDAs that it replaces.
Good stuff.
Garbage Collection Question (Score:3, Interesting)
AmigaDE, Savaje, Symbian and Jeode (Score:3, Interesting)
Another weak study... (Score:5, Insightful)
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
Re:Another weak study... (Score:4, Informative)
It goes straight from source to native; for one thing, the source format exposes stuff that allows it to be more heavily optimized by GCC's optimizer than the bytecode format does.
VM: a definition (Score:5, Informative)
People think of the VM as an interpreter that executes the bytecodes. That's a particular implementation of a VM. And not a very good one -- which is why no production VM works that way.
The simplest optimization is to use a JIT [symantec.com]. This gives you native execution speed once the class files are loaded -- but loading is slower, because it includes compiling the byte codes. You can end up wasting a lot of time compiling code you'll only execute once -- most programs spend 90% of their time in 10% of their code. Depending on the application, you can end up wasting more time on unnecessary compilation than you save by running native code.
Intuition suggests that the most efficient thing to do is to "get rid" of the VM by compiling everything to native code before you distribute your app. But that doesn't get rid of the VM -- it just converts it to a different form. There are some VM features you can't compile away, such as garbage collection. Some experts claim (not me, I get dizzy when I even read benchmarks) that "pure" nativeness is illusory and not that efficient. Plus you lose a lot of the features of the Java platform when you run the program that way. Might as well stick with C++.
Some VM implementations use a sophisticated comprimize between interpreters and JIT compilers [sun.com]. If you can identify the small part of the program that does most of the actual work, you know what parts of the program really need to be compiled. How do you do this? You wait until the program actually starts running!
Advocates of this approach claim that it has the potential to be faster than C++ and other native-code languages. A traditional optimizing compiler can only make decisions based on general predictions as to how the program will behave at run time. But if you watch the program's behavior, you have specific knowledge of what needs to be optimized.
Computer science breakthrough, or illogical fantasy? Don't ask me, I'm just a spectator.
The engineers I picked this stuff up were very contemptuous of "microbenchmarks" like those described in the developerWorks article. Nothing to do with the real world.
The article misses some key points (Score:5, Informative)
After experimentation, I'm pretty convinced that the decompilers on the market that work on obfuscated byte code KICK THE CRAP OUT OF THE OBFUSCATORS. The long and the short of it is the decompiled code is pretty decipherable.
If you want to protect your IP (Intellectual Property), that's not a good thing. In fact, that might be (if you are in a competitive arena) a VeryBadThing(TM). The native code (especially optimized native code) is far harder to effectively decompile into something usefully readable which crackers and script kiddies can abuse or which competitors can peruse. This benefit alone makes it worth going this route if you can.
One of the other things the article missed:
It didn't devote much thought to the settings and optimizations these compilers provide. The Excelsior compiler (by example, I looked at Bullet Train and some others before we picked Excelsior) provides ways to disable certain safety checks (like array bounds checks) for extra speed. If you're in a fairly aggressive environment with some pretty significant timing issues (I won't say hard realtime, because anyone doing hard realtime should be using something like QNX [qnx.com]), you will find that even these small gains may be useful (and the risks they introduce acceptible). But the article didn't even hint at these possibilities.
So, if you want to build something that is less likely to be cracked or examined, this type of tool is the way to go. Excelsior, for example, is fairly easy to setup. I did get some help from their guys, but only because our product includes OpenGL, QuickTime, a bunch of XML parser stuff, DirectX, sound support, UI, etc. - a whole pile of external dependencies. The buddy I recommended it to had his project up in going in half an hour or so, with a more modest project (but still a useful, full fledged app with GUI).
Undoubtedly, these won't solve all your ills and they may introduce some new difficulties in bug hunting (though some of the new debuggers coming out with these products are very neat also). So you will want to look at what you need, what your concerns are (security, speed, cross platform deployment, etc) and decide accordingly.
My Cynical Take on This: (Score:5, Insightful)
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...
Different tools for different tasks (Score:4, Insightful)
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:My Cynical Take on This: (Score:5, Informative)
The point is, I can come in and maintain someone else's code with far less trouble if it's written in Java than I can if it's written in C++. Same goes for the support engineers. Same goes for customers. If it's written in C++, the application can essentially be a language unto itself. You have different mechanisms for just about any major feature between development teams; none of them are standard, and none of them are even remotely as easy to learn and use as the equivalent Java API. Maintaining these applications costs a huge amount, and is fraught with support issues exactly because there are so many incompatible ways of doing the same thing.
Your argument is so tired because it doesn't take into account the actual cost of developing real applications--maintenance and support.
Wrong: Those who say that Java is easier to program in (and who don't know C++) really don't want to learn the disadvantages of programming in C++.What does native compilation gain me... (Score:4, Interesting)
These kinds of articles raise more questions than they answer. I have to ask what does Java native compilation gain me? Martyn writes in the article that performance and memory consumption were basically a wash on the more complex app, so what are the other considerations that might drive me to use a native compiler?
Native compilers have been here for a long time and they haven't really taken off. They either need to offer something absolutely necessary that I can't get via regular Java compilation and runtime, or they need to offer performance improvements that are orders of magnitude better than what we already have. If the vendors can do that, then I want to talk to them. Otherwise it's just another experiment in an already too busy world. Stph
I'm the biggest expert here, listen to me! (Score:5, Insightful)
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!
Hold on. (Score:3, Informative)
The author chimes in, BTW.
Bad review (Score:5, Insightful)
-
for
(long test=2; test < i; test++)
If the compiler generates slow code for that, something is very wrong in the compiler.{ if (i%test == 0) { return false; }
}
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.
IBM JRE is surely the winner....but wait.. (Score:3, Interesting)
Don't get me wrong, I'm a big fan of IBM, and IBM has really, really made a JDK multi-times out-performing SUN's JDK.
However, I'd believe the selection of 'opponents' are simily..unfair.
Kaffe is surely an easy-pick. Yes it's the only GPL JDK out there but many people(at least Java developers here) would avoid kaffe as it has a fatal security flaws [kaffe.org] that kaffe team doesn't seem to want to solve it.
Even the GNU people know gcj is slow, even GNU guys know it; but speed is not a real issue for gcj, it's basically a starting point for all implementation - or reference implementation as we like to call it. We would pick a commercial java compiler if we need it.
SUN's JDK, well...you know what I think it just what you think - IT'S SLOW! Yes, we all know that.
Nevertheless I think developer's work is doing a great job here, it confirms something everybody know - that IBM's JDK is fast, and that's it. I don't see it could conclude the performance of native compiled java programs. Unless they include all other commercial java compilers into testing, I wouldn't think we have reached a conclusion yet.
Java Native Compilation (Score:4, Interesting)
Also see on Javalobby the The "native compilation" myth [javalobby.org] and RFEs for JDK1.5 [javalobby.org] threads which discuss native compilation.
Yes, there are some companies like Jet and Jove (and GCJ) making native compilers, but I'd like to see a company of the clout of Sun (or IBM) make native Java compiling more accessable by having a "javac -native" option with their JDK and a smaller standardized runtime (instead of the full JRE) specifically for native compiled apps. The most likely target for native compiled apps running w/o a JVM would probably for the client/desktop side which don't have the resources of server boxes. Remember... it would be an O