Java Native Compilation Examined 486
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."
HOLY MACRO!
Re:Well gee *that* makes sense.... (Score:2, Informative)
Huh? You still have the Java source
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.
Re:Microsoft .NET already does it! (Score:1, Informative)
With
Re:It's about time! (Score:3, Informative)
Man, JAVA to native compilers exist since 1996 or even earlyer.
Symantec Visual CAFE did it from the first release.
If you enter "+java +native +code +compiler" into altavista.com, yahoo.com etc., you find at least 20 solutions providing that.
The problem is: a java application on linux is no longer able to communicate via RMI or object serialization etc. with an other java application on Solaris or any other OS. You loose reflection support and similar low level access to the runtime environment.
Its a common myth that java is (to)slow
There is even a GNU implementation of a java to native code compiler, since
---> gjc
Regards,
angel'o'sphre
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.
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:Garbage Collection Question (Score:3, Informative)
Bruce Eckel explains some different approaches to GC, pros and cons, etc., especially as it relates to Java. Check out Thinking In Java 2nd Edition, pp. 207-219. You can download it here [mindview.net].
Re:AWT support a must (Score:1, Informative)
Re:AWT support a must (Score:4, Informative)
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.
Hold on. (Score:3, Informative)
The author chimes in, BTW.
Re:It's about time! (Score:2, Informative)
Here you go. [winternet.com]
What's etc?
niko
Free Java Performance Book (Score:2, Informative)
http://java.sun.com/docs/books/performance/ [sun.com]
-Steve
Some gcj facts (Score:3, Informative)
One more rant :) (Score:2, Informative)
With Sun's latest JDK, behavior is different between Linux and Windows, despite it being the same version and from the same vendor.
Example:
Under windows: Component gets both Key and Mouse events, as well as repaints.
Under linux: Component gets key event, but frame traps mouse event. And frame traps repaint as well.
You would think they would have the same behavior... This really makes for write once, debug everywhere.
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++.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.
Toshiba going mobile with ARM chip (Score:2, Informative)
What about the Volano Java Benchmarks? (Score:1, Informative)
The Volano Benchmark, is based on a real world application, and measures the scalability and message passing rate of a real world application. Good Stuff!
Re:My Cynical Take on This: (Score:2, Informative)
Hmm. Do you include debugging and maintenance as part of development? I'm sure you can type C++ about as fast as you can Java, but the work doesn't end there. One of Java's advantages is the vast reduction of memory leaks (not elimination, some guys can leak resources in any language...). In my opinion memory mismanagement is largely responsible for the typical C/C++ bug.
Re:Benchmarks (Score:2, Informative)
Osvaldo Pinali Doederlein.
The Java Performance Report - Part IV: Static Compilers, and More. August, 2001 [javalobby.org]
The Java Performance Report is an independent study of Java performance, where both virtual machines and static compilers are evaluated. Part IV compares Excelsior JET and two other static compilers with Sun's HotSpot Server VM.
Volano, LLC.
The Volano Report. Dec 26, 2001 [volano.com]
The Volano Report covers VolanoMark(tm) - a widely recognized pure Java server benchmark characterized by long-lasting network connections and high thread counts. This report includes Excelsior JET a native compiler.
Excelsior JET Benchmarks [excelsior-usa.com]
From Caffeine and SPECJVM through XML Transformations to Java2Demo and VolanoMark.
Re:Well gee *that* makes sense.... (Score:3, Informative)
I haven't had a single cross platform problem, the one component written in Perl/Tk has caused no end of grief though.
Re:prime example rewriten in C++ results (Score:2, Informative)
Change the Java code to use "int" or the C++ to use "long long" for a fairer comparison.
Re:Garbage Collection Question (Score:3, Informative)
A good source for starting to address all of your garbage collection questions is Jones & Lins' book, Garbage Collection : Algorithms for Automatic Dynamic Memory Management. Another good source is The Memory Management Reference [memorymanagement.org]
Re:My Cynical Take on This: (Score:3, Informative)
Ummm, you might want to check your facts on that one.
Of course, you didn't hear about it here, since slashdot refused my story. I guess the release of a brand new API the largest software company in the world has been working on for years isn't "news for nerds". Download the runtime/compiler here [microsoft.com] or the full sdk here [microsoft.com]
Re:prime example rewriten in C++ results (Score:1, Informative)
$ cat prime.cpp
#include <stdio.h>
inline int isPrime(long long i){
for (long long test = 2; test < i; test++)
if (i%test == 0)
return 0;
return 1;
}
main(){
long long n_loops = 50000;
long long n_primes = 0;
for (long long i = 0; i < n_loops; i++)
if (isPrime(i))
n_primes++;
printf("%lld primes found\n", n_primes);
}
$ gcc -O3 -o prime prime.cpp
$ time
5135 primes found
real 0m41.019s
user 0m40.888s
sys m0.080s
Using JDK 1.3 (JIT) on the same machine:
$ time java prime
5135 primes found
Time taken = 59886
real 1m0.497s
user 0m0.030s
sys m0.050s
$ time java -server prime
5135 primes found
Time taken = 60387
real 1m1.228s
user 0m0.050s
sys m0.050s
I admit that the Java prime benchmark is quite lame, but results like this for Java vs. C++ is pretty typical.
Java isn't slow, GUIs made with Java are slow (Score:2, Informative)
> relatively immature and may not support all the Java classes
> required by your application.... [snip]
> Most notably, there is very little support for AWT,
> making GCJ unsuitable for GUI applications
No GUI? That's where most "users" get the impression that Java is slow to begin with! Java's great for building large, scalable, server-farm applications. Any surprise there, with Java coming from Sun?
If you hear Java is slow, it's usually from a non-programmer who uses Java apps with GUIs or from someone who doesn't use Java when they program their faceless apps. Swing, the platform independent GUI toolset that's built atop AWT (and which gcj doesn't even pretend to support) is incredibly slow, and *that* is what keeps Java with a rep as a slow language. GUI benchmarking is where the story is.
Some argue that end user, GUI'd apps are not what Java's designed to produce, but that's a cop out. GUIs are the only place Java's performance unquestionably suffers greatly. It's why Windows users enjoy Morpheus more than Limewire and it's why Java developers switch from Netbeans (an IDE built with Swing) to Eclipse (www.eclipse.org), which is built on a possible workaround (from IBM) to the GUI speed problem, but isn't endorsed by Sun.
Bottom line -- if you're just pushing 0s & 1s, don't compare the two. Java's found the way to be competitive. If you're putting windows on the screen, you've got Java flat on the mat. That's where the discussion lies.