Now that we are officially in the 64bit era of the iOS app store and our new VM is the default target it has gotten much stabler and helped us track issues that have been a part of Codename One since its inception. As part of improving the VM and fixing bugs we made a lot of changes to the VM including some core conceptual changes.
One of the core changes we made is removing the
. In our original architecture we created a reference counting/GC hybrid which seemed like a good idea in theory. In practice reference counters are surprisingly slow (despite their inaccurate reputation) this is mainly due to multi-threaded access which makes the reference counting code problematic. We tried many approaches but eventually after many experiments we just removed the reference counter completely and saw a big speed boost. Since our GC is concurrent and never stops the world (it can stop the allocating thread if its out of RAM) you shouldn’t see any stalls assuming your thread yields properly.
Removing the reference counting logic reduced code size by 20% which helps speed up compilation and the overall app performance so this is a pretty significant leap. Doing that helped us leapfrog past the performance of the previous VM in most (although not all) benchmarks. With the new VM compilation time is often under 2 minutes as opposed to 5 minute compilation time on the old VM, this alone justifies the effort in migration.
We also came across several “gotchas” in the new VM that you should be aware of:
Default encoding – the old VM defaulted to US-ASCII as its encoding where the new VM defaults to UTF-8. UTF-8 is slightly slower so you might want to explicitly use US-ASCII.
Exception performance – Exceptions in the new VM are really slow by comparison. This is mostly because we create the stack trace data before throwing which is somewhat inefficient. This shouldn’t be a big deal as long as you don’t use code that relies on exceptions for better performance e.g. looping an array until array out of bounds exception is thrown. This would be slower than just using a standard if.
- Thread overhead – The new VM take up a bit more RAM per object but this is very noticeable in threads. Every thread can take half a megabyte in RAM to get started! This is pretty expensive but there is a reason. The new VM allocates stack objects for all the data within the thread stack frame. Furthermore, every object allocated within a thread is stored by the thread and only placed into the global pool when the thread and GC thread sync. This allows allocation code to be lock free and very fast as a result!
On a completely different note we now have a new Demo in SVN titled Property Cross that demonstrates property search in the UK. It allows you to search a UK database for houses for sale and then scroll an infinite list of properties. Mark your favorites and get additional details on them. We’ll try to post a detailed tutorial on it in the coming weeks.
Notice: This post was automatically converted using a script from an older blogging system. Some elements might not have come out as intended…. If that is the case please let us know via the comments section below.