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)
Runtime bounds checking, typecast checking, etc... do those get included in the native executable as well (and if so, then wouldn't the performance hit negate the advantages gained thru native compilation?), and if not, then it could be dangerous.
There's 10 types of people in this world, those who understand binary and those who don't.
The program used in the benchmarks was very simplistic .. I would rather have seen a program creating and destroying many objects of various sizes. In the nativly compiled version, how does garbage collection work? Is it possible to write AWT apps? Swing?
The two things that throttle Java's performance are Swing and the garbage collector. Swing isn't *that* big a deal -- like Mozilla's XUL it's been sped up over time -- but doing garbage collecting is a very complex task and will probably eat up CPU cycles like mad for at least the near future.
That isn't to say garbage collection is necessarily a bad thing -- it's good for security and portability (the two things Java really aims for) since it eliminates the need for all those nasty pointers. But it's the main reason C++ code can runs circles around similar Java code. And doing native compilation won't help the situation any.
This is built into the .NET Framework. Run ngen.exe on any .NET .exe or .dll and the MSIL is precompiled into an optimized native binary. In fact, setups for .NET apps can do this on the assemblies they install. Indeed, the .NET Framework actually precompiles its managed shared .dlls on install time.
Seems to me the problem with Java is that it waits until memory is full to garbage collect. In C++ Code, if you allocate and free a lot of memory, eventually you are going to fragment your memory to the point where you may not be able to allocate large enough memory blocks for your purpose. GC is supposed to get around that. But if C++ doesn't GC, how can a C++ app run indefinitely. I would really appreciate someone who understands the subtle nuances to explain. If there are better memory allocation schemes, couldn't you use them until you were forced to use GC?
Open Source Identity Management: FreeIPA.org
I was a little disappointed in the selection of the the JVM's they selected for their example. Especially now that PDAs/CellPhones are now powerful enough to run real applications on the client. I have yet to see a StrongArm device ship with the Sun, IBM, or KaffeJVM, why, because they are slow. The JVMs listed in the subject line run 10-200x faster on devices. Soon we will see EJB and other J2EE compents on PDAs. As a developer of client java applications/applets I would never distribute a device specific application, it would be a nightmare to have 160 diiferent compiled versions of the same application. The good JVMs already have done that, and my code I compiled years ago works on the newest PDAs...So there
"Get them before they get....
Dallas Semi makes the TINI, a Java implementation in hardware packaged as a 72-pin SIMM stick. I have one and it's cheap and fun to program. Built-in ethernet, general purpose IO pins, etc.
Go here for more info.
It seems like you might not have read the article all the way through. It doesn't recommend only native compilation, but it does make a nice comparison between the two solutions. It points out when you might want to take advantage of native compilation, and when it doesn't help. You are always free to generate byte code in addition.
Much of the work I do would be nicer and easier in Java than in other languages, but Java is just too slow and large for my purposes. This gives me the chance to use a language that has a little elegance, without giving up the speed of execution that I require. C++ just doesn't cut it, and it's tough trying to write this kind of code in C (but not impossible, it just takes a little discipline).
Java isn't really cross platform anyway. Where's the JVM for MVS?
The difference between a Miracle and a Fact is exactly the difference between a mermaid and a seal. (Mark Twain)
Have you benchmarked the Boehm collector?? (incidentally, it is the collector used by GCJ).
Its a reasonably fast GC, especially if you turn off incremental collection.
Its still a 50% slower than manual memory management on a good day. And you can get a lot faster than either manual or mark/sweep GC with an intelligent hybrid of manual management, pools, and custom allocators. Of course, you pay for that speedup in terms of requiring more sophisticated (read expensive) developers.
Which brings us to the real reason people use Java. Java programmers are cheaper, since you can hire less skilled programmers and not worry about then leaking memory all over the place or blowing away unrelated parts of memory. This effect, along with rampant VM bugs, explains why use of Java doesn't increase software quality.
That's probably because there's really no way to obfuscate Java byte code, since it's all java.lang.reflectable anyway - you can use Java code to dynamically load a class name at run time and then discover methods it contains and public variables it has.
As far as I know the .class format in essense requires methods and class variables to be determinable makes it fairly hard for Java to be "secure" when it comes to making code hard to disassemble. Especially because all your classes wind up being one-class-to-file and by default end up with the names of the classes and the package structure laid out in the directories created...
Sun may want to consider creating a secure JAR file which is loaded by a "secure" class loader that prevents reflecting, but a lot of cool stuff can be done with the reflect interface (like loading plugin classes at runtime).
Bottom line is that every .class file contains a list of all methods and public variables as well as being one instance of an original class definition - not useful for making your program structure hard to dissassemble. However, the ability to determine methods and load classes at runtime can be useful to. (As well as required for Java's RMI, I think - I might be wrong, though.)
You are in a maze of twisty little relative jumps, all alike.
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
It's being done by IBM, anyone would think it's biased? :)
:)
:/ (We call Kaffe 'MS' JDK'2, not just for humor, but it's really the case. ^_^)
:D
:)
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 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.
Binary cross compatibility doesn't exist with java in it's current state. Try byte-compiling on linux and then running it on windows.
Until binary compatibility there is, running with java you will not.
~
MU!
One of the best articles on native compilation is this performance report
Also see on Javalobby the The "native compilation" myth and RFEs for JDK1.5 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 OPTION in the JDK... the old bytecode compiling for VM/JIT would still be there.
It's arguable whether the runtime performance of a native compiled app would be substantially better than JIT compiled (if some of the Hotspot tricks were moved upstream into the JDK compiler?), but there are also other advantages, such as a faster startup time (no need to startup a VM processes and JIT compile) better memory usage (no need for VM process as well as the meta data and bytecode which must be held in memeory). There would also be some drivespace savings as the full JRE wouldn't be needed (though at this time, a developer can't include a partial runtime, Sun wants the full thing if they include one... Sun needs a change of heart and make a standardized smaller runtime for native apps). Also, with native binaries an obfuscator (used for btyecode classes) isn't needed for commercial apps for those who want to keep their code proprietary.
There are lots of suggestions going around for the VM/JIT issues such as loading the VM at bootime, a singular shared VM, and JIT caching. These workarounds aren't neccesary with JVM-less native compiled apps.
Of course, there are WORA extremists who don't like this idea of native compilation because it goes against the dogma of only needing to compile ONCE and run on any OS with a JVM. IMO, as long as the source stays the same, compiling natively for different OS's is still pretty near to the WORA ideals. The Java language is VERY tweaked for portability as-is. It's the OPTION of native compiling that should be available in the Sun or IBM JDK.
This is not the case anymore. An example is Zelix Klassmaster. We use it for our java web application. No decompiler can cope with it. The decompiled code is littered with byte code that it couldnt work out what to do with. I wrote the code, and I cannot for the life of me work out which methods are which in the decompiled after obfuscated classes. They also do things like String encryption so even string constants are unrecognisable.
Java is certainly not perfect in this respect, but my experience with obfuscation (this is very recent) has been very good.
dominionrd.blogspot.com - Restaurants on
>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...
,Dinkum, etc for instance. As for garbage collection, I myself have 7 different conceptual collection systems implemented that can be easily integerated into any code you want.
I have yet to be proven wrong that developing using C++ is any harder or time consuming than writing in Java. Arguments for usually revolve around Java's libraries and its garbage collection.
To that i say Java's libraries are outclassed and outnumbered by the amount of source for C++ and the number of libraries like Boost
I can even make the case that developing for C++ is easier given the use of templates. Those who say that Java is easier to program in really don't want to learn the advantages of programming in C++.
The richness of a language's vocabulary is what lets its speakers express themselves in powerful ways distinct from what other language speakers can do. French has a number of terms and concepts that don't have direct translations in English, and in fact, a huge amount of common English vocabulary comes from French.
A programming language's libraries are equivalent to a natural language's vocabulary. And this is exactly where Java shines the most from an application development point of view. (It shines for other reasons on other fronts, like for embedded programming.)
Sure, you can go out and develop a C++ app without using pointers, but that's just one app. The next one probably will use pointers. Even if I become a C++ programmer and refuse to use pointers in all my applications, I will have to work with someone who does, or use a library that requires them (is there one that doesn't?). And, eventually, I'll have to maintain someone's code that uses pointers. In the end, there's no getting away from it. Java eliminates the vulnerability pointers represent unilaterally, for better or worse.And similarly, you can go grab a library for doing garbage collection, but which one? You have nearly infinite choices, and every app will make a different choice. It's exactly the consistency of features that make Java superior in this regard. And when I say superior, I mean cheaper, and not just in terms of money, but in terms of resources. The support engineer trying to fix a bug in a Java program won't have any questions about the subtleties of a garbage collection API he's never seen, nor wonder what's in this odd little pointer that seems to keep causing a production crash. These are real advantages, even if they are hard to quantify.
That's just the limit of your experience then. My experience is exactly the opposite. The advantage here is the fact that you maintain a single codebase--the same source files--for all platforms, and they do work as advertised minus any VM bugs (which are fairly rare compared to application bugs).Let me tell you a story. I used to work for one of the real success stories of the dot-com era. My company implemented different pieces of its product using Java and C++, and these pieces used CORBA to interoperate. As far as any one distributed object was concerned, the object on the other end could be any language; it was only a difference of implementation.
Anyway, the support and maintenance costs for the Java portion of the product were dramatically lower than for the C++ portions. They both used the same infrastructure, but one was cheaper and faster to develop in, easier to fix and enhance for the next version, easier to debug both in-house and in the field, and more stable to boot. Add to this the fact that you only had one copy of the source files for the Java portions, versus the several versions for all the different platforms we supported in C++. In the end, if you work on large, complex software systems, Java is vastly easier to maintain, and vastly cheaper to support. Ask any of the product engineers and they would say the same thing: Java is just more pleasant and productive to work in, and they prefer Java over C++. They all hated the C++ portions of the product, and regretted ever putting them in.
And, sadly, most programmers out there aren't that good. With C++, you give them a loaded weapon and tell them to be careful. As often as not, they inadvertantly shoot you or themselves. At least with Java, poor programmers have to load the gun before they can shoot anyone. Sorry for the extended analogy.
Ugh, so much to say here. The problem is that what you are suggesting is a myth; it does not represent the real world of enterprise application development. You don't know your platform, it is not a constant in the equation. You want to provide for all platforms if you're a software vendor. Once you can sell to one, using Java, you can sell to all others without any significant extra effort. Furthermore, bugs fixed in one version of your code are fixed in all versions--support costs go down dramatically.If you're a client, you may find that you are grossly unsatisified with vendor X's hardware/support/performance and want to switch to using a solution by vendor Y (and this happens all the time in the corporate environment). What do you do now? Just because you know things are changing doesn't make the cost of changing any less. However, the fact that you wrote your application in Java does make the cost less--it makes it nil, because the same code runs on HP, Solaris, Intel, Windows, Linux, MacOS, AS/400, etc. The ability to move code effortlessly between platforms allows you as a company to save costs if it makes sense to switch hardware platforms, or mix and match platforms.
Yes, but the application code your GUI fronts is also cross-platform. Not so with the others. And again, there's the benefit of the single binary versus a binary per platform. That's fine, but it really is. Try it. The limited complexity of the language lets programmers focus on the task at hand far more easily in my experience, and it's much easier to do OO in Java than in C++. This means all the benefits of OO are more easily achievable (and if you don't think OO is a good thing, don't bother talking to me.) If you can, great, but I haven't found that language yet. It might be Smalltalk, or Perl, or COBOL, but nothing so far has taken all the great ideas from all of these languages and made them so eminently useful and practical. For example, Smalltalk is probably the most elegant, most forward-thinking languages around (even today), with tons of powerful features. However, it doesn't have the network orientation that Java does, or the C/C++ like syntax that makes it easy for developers to learn. It doesn't have the ability to be pared down and run inside a DIMM-sized computer, or be as dynamic as Java.I'm not advocating Java over other languages if those languages are more suited to the job. I'm not going to write a device driver in Java. I'm suggesting that a task that can be equally accomplished in Java and some other language will be more maintainable, cost less to support, and completed more quickly, when written in Java. The real-world merits of Java are that it reduces resource costs for anyone using it, end of story.
The only certainty is entropy.
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...
CrazyLegs
"Pork!!" said the Fish, and we all laughed.
There is one thing wrong with this process; rebuild. The latest generation of Java dynamic compilation/optimization does its work behind the scenes and happens automatically which I think is a huge advantage over FDPR. It allows the optimizer to adapt to unforseen changes in the production environment.
I think that Hotspot-style dynamic optimization is the future of Java and will eventually overtake statically compiled (or repeatedly compiled) options.
However, Hotspot has a lot to learn from FDPR, like how to keep track of performance metrics across VM sessions. The biggest drawback of current Java dynamic optimizers is that you only get their full potential for long-running processes. Once they get optimization profile management down, the dynamic optimizers like Hotspot are going to look much more appealing on the types of benchmarks like this article uses.