Slashdot Mirror
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."
← Back to Stories (view on slashdot.org)
Huh? You still have the Java source
Good progress is being made in native compiler for Palm OS. See http://sourceforge.net/projects/jump/
and also http://www.superwaba.org for info on the related JVM for PDAs that it replaces.
Good stuff.
Beta only seems to work for Google. Such a shame.
What's cool about the .Net JIT system is that the MSIL is actually an intermediate stage of compilation (currently available for C# and VB.Net). The output of the JIT is an actual binary executable like those produced by C or C++, i.e. no runtime needed except when accessing .Net-specific functionality.
.Net there isn't any interpreter (unlike the current VB).
With
I was waiting for this to happen.
... the way to compile it to native code exists since 3 month later since java was widely adopted.
... 3? years?
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
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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. 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. 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.
First, I have to identify that we (my company) do use the JET byte->native compiler by Excelsior. Good product, I've recommended it to others and they've had success with it too. In our case, it produced a 10-15% speed increase, some in-memory size savings, and it had one huge advantage missing from the byte code: SECURITY!
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), 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.
-- Mal: "Well they tell you: never hit a man with a closed fist. But it is, on occasion, hilarious."
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.
I would really appreciate someone who understands the subtle nuances to explain.
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.
A simple GUI java application now can run and be semi-usable in gcj (in 3.1) but there are still bugs and more to implement. Help either the Classpath or gcj, they are in the process of being synced up together (see http://gcc.gnu.org/java/).
Having used JET somewhat extensively, I can say that Swing works beautifully in it... exactly as you'd expect, and at a reasonable speed, to boot. It doesn't make small applications, but it optimizes relatively heavily. There's more than hope: it's already there!
I've had this sig for three days.
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.
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.
There's a thread about this article over at the gcj's mailing list: here.
The author chimes in, BTW.
> (no operator overloads, etc).
;-D
Here you go.
What's etc?
niko
http://java.sun.com/docs/books/performance/
-Steve
Why is everything inconsistent?
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.
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++.The only certainty is entropy.
What VM are you using? I haven't seen a significant problem with moving apps between machine architectures since Java 1.3 came out.
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.
ZFS: because love is never having to say fsck
No JVM for this baby.
A feeling of having made the same mistake before: Deja Foobar
I have yet to be proven wrong that developing using C++ is any harder or time consuming than writing in Java.
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.
MSN 8: Now Microsoft even has bugs in their ad campaigns.
Osvaldo Pinali Doederlein.
The Java Performance Report - Part IV: Static Compilers, and More. August, 2001
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
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
From Caffeine and SPECJVM through XML Transformations to Java2Demo and VolanoMark.
Exactly my experience, I've written a set of Oracle database administration tools with image display & mp3 playing capabilities, they were developed under Linux and run out of the box under Solaris, NT & OSX with a 1.3 runtime.
I haven't had a single cross platform problem, the one component written in Perl/Tk has caused no end of grief though.
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. (Einstein)
Your C++ version is not comparable. A "long" in Java is 64 bits. A "long" in C++ is 32 bits. The Java code is doing far more work.
Change the Java code to use "int" or the C++ to use "long long" for a fairer comparison.
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
That's funny, since .net and C# aren't even the present yet.
.NET has shipped. (at least, visual studio.net and the .net framework). You can download the release of the compiler and the SDK on MSDN.
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 or the full sdk here
DO NOT DISTURB THE SE
Even with the "long long", C++ is still 50% faster than Java/Hotspot (and uses one third the amount of in-process memory):
./prime
$ 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.