I've been following Bug Labs choice of JVM quite closely. After a series of comparisons between JamVM, CacaoVM and PhoneME they adopted PhoneME (initial test here and the follow-up). I blogged on the results of the first test, which were favourable to JamVM. However, for the second test, they sorted out the problems with running PhoneME's JIT, and the positions of JamVM and PhoneME reversed.
This was disheartening, but the results spoke for themselves. However, one odd fact is that the second test did not give any details of start-up time. JamVM clearly won this in the first test, and it's unlikely enabling PhoneME's JIT would have changed this.
So, I read with great interest the recent blog entry where they've got CacaoVM/GNU Classpath running on the BUG. It appears they will still ship with PhoneME, but CacaoVM/GNU Classpath will be an option for customers who require the Classpath exception.
So what? Well, I'd like an explanation why they seem so reluctant to use JamVM. From their own tests, JamVM came out on top for start-up, and came second in performance to PhoneME with JIT.
Perhaps they've finally cracked the performance problems with CacaoVM. But JamVM is not configured for top performance on ARM either (by default, the inlining interpreter is disabled on ARM).
Of course, there are many other advantages to JamVM on embedded systems besides start-up time. It has its own, compacting garbage-collector with full support for soft, weak and phantom references in addition to class unloading. CacaoVM relies on Boehm GC, exhibiting memory fragmentation issues, and it has no support for soft/weak/phantom references or class-unloading.
Things like this makes me very disheartened. As I've said before, it makes me wonder why I continue to work on JamVM at all. However, giving up will be a case of "cutting my nose off to spite my face".
If they've hit any problems with JamVM I'll be quite happy to work with them to fix them, but I've received no feedback or requests. Unfortunately, I have been unable to leave any comments on the blog entry itself. On enquiring with the webmaster, it appears that this is new software which is at an early stage. However, they've put this functionality at the top of their TODO list, and I can expect it in a day or two (thanks Brian).
To finish on a positive note, I've done quite a lot of work on JamVM over the last few months, including memory footprint and performance improvements over JamVM 1.5.1. Hopefully I'll make a new release before Christmas.
Subscribe to:
Post Comments (Atom)
3 comments:
Don't be disheartened! We are Stay tuned, we'll have a JamVM-based release out soon. In terms of CACAO over JamVM, it was simply a matter of CACAO being further upstream (OE dev) from JamVM (Jalimo) in the OpenEmbedded world. We love JamVM and our very first prototypes used it! Additionally, this CACAO release is for one specific partner, not a general strategy for a CPE BUG platform.
thx
ken
Robert your work is great, I really appreciate your hard work, jamvm is a wonderful project. I don't understand why buglabs don't use jamvm, I really don't udnerstand and I have asked them some months ago. I'll be waiting for your xmas gift! thank you.
I used JamVM back in `07 for my Gumstix/dsPIC based MicroMouse. While the Java universe might have changed quite a bit since, I just want to say I really appreciated your efforts back then and I'm happy to see JamVM development continue. I look forward to using JamVM in my future projects... not only is JamVM small, it's standards complaint, fast, stable, and a breeze to use. Thank you!
Post a Comment