Here is what I saw on the dev's Blog. Located here:http://blog.mozilla.com/blassey/
Brad’s Blog
thoughts about Mozilla and mobile
Memory Dragon Slain
03.23.09 - 10:51pm
The pre-alpha build we
released in February got a lot of criticism (and rightfully so) for what became known as the “checkerboard” issue. Mark Finkle blogged about the
problem and the
solution before. Tonight I pushed the fix to mozilla-central, here are some details.
It all comes down to memory.
Simply put, we were running out of memory. The frustrating part though, was that we weren’t running out of
real memory. We were being constrained by an artificial limit of 32Mb (including the binary) that Windows CE places on each process. That is why otherwise extremely capable phones like the HTC Touch Pro with 288Mb of RAM were showing a beautiful checkerboard pattern. I’m still not entirely sure why this didn’t show up on our development devices before the release. I suspect it has something to do with the fact that we’re using unlocked HTC Touch Pros for development, while most of the testers seeing the problem were using handsets from Sprint, Verzion or AT&T.
Digging further, the reason people saw a checkerboard pattern, but otherwise usable UI is due in part to the way Fennec works. In Fennec, the user actually interacts with an html canvas element. We render the page off screen and then paint the image onto the canvas. In this particular case, it seems as though we were successfully rendering pages but failing to allocate enough memory to do the final paint onto Fennec’s canvas. We were handling this low memory “gracefully” and continuing to run.
jemalloc to the rescue
At first Doug Turner took a crack at cooling down this memory hot spot by improving on how we allocate memory during paints. Essentially, allocating a single buffer and reusing it every time he needed a surface to write to. This didn’t actually decrease the amount of memory we were using, but instead significantly reduced the amount of memory “thrashing,” (repeatedly allocating and freeing chunks of memory).
With that change we were able to run for much longer without running into memory problems, but it became clear that there are plenty of other places in our code that we thrash.
The solution was to use
jemalloc, originally written by
Jason Evans. Stuart and Vlad
used jemalloc to greatly improve the memory performance of Firefox over a year ago, so it was already in the Mozilla bag of tricks.
Success!
Fearful of counting my chicks before they were hatched, I didn’t want to blog about this until it landed, and tonight it did. With jemalloc enabled on our windows ce build of Fennec I am able to start up without any worries of seeing a checkerboard.
![](http://people.mozilla.org/%7Eblassey/wm-screenshots/firstrun.png)
…and I can browse to the two most memory intensive websites that I encounter on a regular basis (both of these have crashed my iPhone on occasion), the first being
Planet Mozilla
![](http://people.mozilla.org/%7Eblassey/wm-screenshots/planet.png)
…and the second being the
Firefox tinderbox waterfall
![](http://people.mozilla.org/%7Eblassey/wm-screenshots/tinderbox-3-21.png)
I can even look at both at the same time!
![](http://people.mozilla.org/%7Eblassey/wm-screenshots/tabs.png)
With these bugs closed, we’re down to 5 blockers for our next release on Windows Mobile. Stay tuned.