I met an employee at Thoughtworks (until then I hadnt heard of the company). Its a software consultancy based company completely based on open source and focussed on quality and performance.So these guys try out all the newly released versions of open source software and conduct variety of unit tests and several other benchmarks to test out improvements and select the best Open source app for the customers. The discussion this time was regarding JDK 6.
The newest release, in its JIT compiler improvements, produces targetted code compiled to exploit the benefits of the microprocessor architecture of the running machine. Also the adverse effects of reflections (where some common method calls loop over 50 or so times before getting to their destinations) and method call loops seem to have reduced drastically due to better optimizations in the JIT.
The result, as claimed by thoughtworks, is that JDK 6 provides 2.5 times better (faster) performace than version5. Theres more on this performance improvement here, and how best to exploit it here
Some additional info about the performance improvements:
Many deployers in the field, using pre-release versions, have reported noticeable runtime performance improvements, in the "two-digit range" according to Sun, which translates to anywhere from 5% to 24% improvement. Note that this is anecdotal, of course, and depends on what tasks you're performing. However, the JIT has been improved, with better runtime analysis of program characteristics, and the performance improvements have been agreed with by external users.
Desktop support may not be as relevant for the enterprise community, except for rich clients. System tray support, splash screen support, and other elements have been added.
JSE6 now has dynamic language support. It comes pre-delivered with Netscape's Rhino, a Javascript engine, and the scripting project's home page documents many other available scripting languages, including Ruby, Python, awk, Jelly, Pnuts, and Scheme.
Java SE 6 also has new diagnostic capabilities. For example, profilers and debuggers can now attach to a running JVM without specifically using a debugging-capable configuration. For example, if a problem is found at run-time for a production server, a debugger can attach to it without restarting the server, a valuable feature for issues that show up after the server has been running for a long period.
Now, when one talks about performance, the obvious notion is that nothing can get better than targeted assembly code. But thats zero on interoperability, so here's java for that. But somewhere on this transition, the performance suffers partly on effects of interpretation of bytecode and various other overheads. Needless to mention, the JVM on various platforms are not exactly quite consistent in their look and feel, so application starts looking and behaving differently on different machines. Of course for the performance critical (or real time) applications, C/C++ would be the default preference for producing fastest code with some lever of interoperability.
This always has been the belief to the extent that it has been generalized to imply that "any language in its native form gives better performance than one that runs on a virtual machine like jvm". That belief comes now to be questioned as it is claimed (by thoughtworks again) that JRuby runs faster and is better space optimized than native Ruby itself. The explanation is that this is accounted for by the superior JIT compiler optimizations which ensure coherency among objects being accessed together.
Seems like the easier route for developers may not actually tax them on performance anymore. But its just the beginning. I havent really tried out version 6 so far, but user targetted apps with interoperability in mind definitely must go in for it as the best option.
