Java VMs Compared II
We received great feedback from our previous comparison of Java virtual machines. We acted on all of the comments we received from the Cacao community by tweaking our build configuration. Additionally our upcoming 1.3 release includes a newer Linux kernel (2.6.24). This alleviates the problems we had with phoneME’s and JIT. Here are the same benchmarks we used previously, reflecting the new build configurations.
PhoneME really came into its own now that JIT can be enabled without causing the system to crash. It will be great to pass on serious speed improvements to our users. those who upgrade their software should be able to notice the difference in speed (along with many other great improvements).
Unfortunately, we had little success improving Cacao’s performance. We significantly delayed posting this so that we could try tweaking the configuration as much as possible, but there was no pay off. On most hardware Cacao will benchmark faster than JamVM, and should come close to phoneME. For some unknown reason the combination of OpenEmbedded’s Cacao and our specific hardware does not perform as expected. You should test Cacao on your own hardware for a more accurate portrayal of its performance.
However, phoneME is not perfect. There is a major difference between using Cacao with the GNU Classpath libraries and using phoneME with its library. GNU Classpath is aiming at a J2SE sized set of libraries, while phoneME is J2ME-like so this is to be expected. But phoneME is significantly more short of J2ME than Classpath is of J2SE.
The biggest of detriment of phoneME is the graphics toolkit. With PhoneME we are limited to the AWT toolkit, the original Java GUI library. It has many limitations – from its simple aesthetic appearance to feature shortcomings like the deficient graphics library. PhoneME doesn’t have JSR 209 – Swing for J2ME, since it has not been open sourced. It is also missing several other libraries you need for Mobile Processing. With Cacao we can definately use the Swing library, and most likely can use all of Processing.
Compare the two screen shots below. First up is the TipCalc application using AWT. The second is the same application converted to use Swing. The difference is quite striking.
For now we will continue to use phoneME, but there are some other options for a better interface. Perhaps the most interesting is the new Lightweight UI Toolkit (LWUIT). It feels much like Swing but is significantly easier to port to our system. Another option is the Clutter toolkit, currently used by the Poky applications in our distribution. It currently has no Java bindings but does them for Python, C/C++, and Ruby (among others). A Java binding would certainly be possible. With back end support provided by OpenGL, it would allow us to do more graphical applications than are currently possible.
While new GUI libraries are not going to be coming in the near future, you will be seeing our 1.3 release of the file system very soon. This will bring significant speed boosts to your BUG, so stay tuned for an announcement on a final production tested version.
If you want to jump in and play with the development version now, code is always available and the associated documentation has been posted. And don’t forget to join the Bug-Dev mailing list to get involved with our development discussions on topics like these.
For those who are not BUG users and are just interested in the benchmarks of VMs, I hope these help guide you in your decisions. However we must caution that the VMs perform quite differently depending on your processor. Several people responded to the previous post by running these same benchmarks on different hardware and came up with a completely different result. Our benchmarks are quite repeatable on our hardware so we are confident in these results for our case, but your case might be entirely different. The benchmarks are available here and here, and the time benchmarking takes compared to the value of the results makes it definately worth doing.