I’ve been flashing CyanogenMod 9 nightlies for months now, and the process to do so has become pretty much muscle memory at this point (if cwm ever changes its menu order I’m screwed). One step of this process has always fascinated me simply because I have no idea what exactly it does and why I have to do it: clearing Dalvik cache.
The process of upgrading CyanogenMod 9 nightlies for the Samsung Galaxy SII is pretty elementary, and basically, anyone can do it (hence even I never had it fail).
- Download latest nightly
- Transfer to device
- Reboot into cwm
- Install the nightly zip file
- Clear cache
- Clear Dalvik cache
- Reboot
This whole process takes only a few minutes, so I usually do it a few times a week. Now that CM9 has become a bit more mature, the improvements between each nightly have gotten smaller, so there’s no need to keep up with every single one of them anymore.
So, it’s step 6 that has me wondering. What exactly is happening when the Dalvik cache is cleared? Obviously, cached data is being removed, but what is in this cache? What is its function? Regular application data isn’t part of that particular cache, so I’m guessing it’s way more low-level than that. I have little to no knowledge on Java either, so I don’t really know what kind of cache a Java VM needs in order to function, and why it must be emptied when you move to a new nightly.
Searching the web reveals several forum posts on the issue, but nothing conclusive or truly informative – it usually devolves into a discussion about whether or not it’s even necessary in the first place. Do any OSNews readers have the answers to these questions in a more definitive sense?
My understanding of it is that in the process of installing an Android app onto a particular device, various optimizations are made to its Java class files in order to perform more efficiently on the particular hardware contained in that device. These optimized variants are stored in the cache so they don’t need to be recomputed each time (along with any JIT optimizations that are made as a result of runtime analysis of the program after you’ve run it a few times). Since the bytecode format can change between Android versions, that cache would potentially need to be cleared to force all that to be regenerated in the newer format.
The word you are searching for is AOT compilation cache.
(the android cache partition also contains some data)
Will try to remember that, thanks!
Not necessarily. Dalvik doesn’t do AOT compilation. It does do resource optimization and layout formats.
Though it definitely would be nice to add that.. There’s no need to re-JIT the on-screen keyboard task every time it’s loaded…
Having the code mmapped also reduces strain on the memory management (since filebacked mappings can be dumped to storage easily).
Would also create opportunities for expensive optimizations which could be scheduled for when the device is “asleep” and externally powered.
Essentially FX!32 for Dalvik.
Thanks for the clear answer, Rene!
If you want a more nitty gritty detailed explanation, read this:
http://www.netmite.com/android/mydroid/dalvik/docs/dexopt.html
Also, just fyi – this is the stuff a large chunk of the Oracle patent lawsuit was about… Namely whether dexopt was violating Oracle’s patent on dynamic optimizations. The end result of what they were arguing about is what ends up in the dalvik cache.
I’ve been using GooManager for a while (yes, it’s on Google Play) to flash the nightly CM9 ROMs on my HP TouchPad – it might knock a step or two off your procedure, Thom! A bonus with GooManager is that it lists non-CM9 ROMs too, plus knows about the various Google Apps versions and will let you add those as well.
Edited 2012-07-10 18:26 UTC
RomManager anyone?
It used to work great for CM9 nightlies. For some reason it doesn’t list them, only the CM7’s now.
In any case, a nightly in late june screwed up wifi bandwidth or latency. Then I screwed up and accidentally installed a CM 7.2 over CM9 with not fun results. Had to do a full wipe of data to get the phone working again. But it works great now!
I prefer doing stuff like this in a sparse and Spartan environment – it better fits the task. On top of that, I prefer the old-fashioned non-touch cwm, since using touch instead of the physical volume/power buttons just seems like a very stupid idea for dangerous and possibly destructive tasks like this.
Actually, you don’t have to wipe the Dalvik cache. Or the regular cache for that matter. They will be automatically refreshed as required.
Yeah, right.
that is definitely not my experience.. the number of problems I’ve had with my own custom roms that are as a direct result of not clearing the cache….. too many to count..
I wish it worked as the docs say.. maybe i miss something in my config
While that is true for a non-rooted device, the minute you root an android device it goes out the window. Once you have rooted you have put the device in a state where it is entirely possible for things to get seriously out of whack because you will of course start installing things that don’t follow all the rules religiously. That and odds are you will start changing boot-loaders and ROMs and other things that were _never_ meant to be changed in isolation, and there are different tools that do this differently – some clear the caches for you automatically when they think it is the right thing to do, but some don’t…
In short, it is certainly possible to get away with not clearing the dalvik cache, but the rules are so complex as to what you can and cannot do without requiring a cache clear that it is simply more reliable to _always_ clear the cache when making a low level change. Think of it as good hygiene.
Well, I guess it depends on what you’re running. When you update (to) a CM9 rom you’ll notice that at the first boot Android is rebuilding the cache for all applications. THAT’s the Dalvik cache rebuilding afaik.
So it seems we are all right. Yes, the Dalvik cache needs to be rebuilt, but you don’t have to manually wipe it.
You all are partially right, there is no need to wipe dalvik cache after flashing a nightly build as the installer script does it for you, but, it is not always neccessary at all, only when there have been changes to the dalvik-vm, which indeed happens relatively rarely. However to be on the safe side cm does it on every flash.
So Thom, if u want to ease the process of flashing nightlies, get the rom manager pro (its worth those few bucks) and use it to download and flash the latest one, the pro version can even be used to notify you if a new version is available.
What is it? I have no idea. Is it truly necessary to clear the cache? Well on my first Android phone, a Motorola Cliq (SB200), if I didn’t clear it the phone would crash after installing or updating CM7. On my Nook Color, I once forgot to clear the cache and it still booted fine.
I wish I could offer more but that particular subject is over my head.
I could be wrong, but some of the optimizations could be between different intermediate files (classes for example), and if there is a slight change in one of those interfaces between versions, the optimizations might no longer work. Therefore it could result in failure to boot (if the application was critical to the system), or maybe just some force-closes.
Again, pure speculation…
That is where the “ODEX” files are stored for each application, that applies to all ROMS that are deodexed.
Java is compiled to processor independant bytecode so you can run it on any device which has a JVM which understands that bytecode. The bytecode is “the program” you download onto your device.
That bytecode than gets “compiled” at runtime optimized for the processor it is running on (x86, ARM, AMD64, etc.). This is what they call Just-In-Time compilation is. Depending on how JIT is done, it can mean that only the part of the code that is used will be JIT compiled.
As some examples: PHP files are also compiles to bytecode before it is run. The bytecode is what is actually ‘running’ when a PHP-script is doing it’s work, it is interpreting the bytecode.
JavaScript doesn’t use a bytecode intermediate, I believe. But it does do the JIT compilation to optimise for the processor it is running on.
Anyway, I assume the cache you mentioned is the used for the result of the JIT compilation.
And the reason why it needs to be cleared I guess is because for Android system classes it would always use the JIT and not even check if it the bytecode is newer/different/has been updated.
Edited 2012-07-11 11:53 UTC
Seems I was wrong, at least the Firefox JavaScript engine (and I assume the other do too) compiles the script source to bytecode as well.
Overall, you mix a bit carelessly interpretation, compilation, and JIT over there.
beautiful sharing, really interesting, keep it up
9th calss result 2012
http://www.biseresult.pk/9th-class.html