Home ยป Monthly archive

April 2009

Disabling the cache

  • Posted by balazs.kelemen at 04/28/2009 - 15:24

A goal of mine is to decrease and limit the memory usage of WebKit. In embedded environments, memory can be even more important than performance. I was interested how can the memory consumption be lowered with the functionality already present in WebKit's code base, i.e., without too much hacking of the code.

The battle for the title: the fastest ARM JavaScript Engine. Round one.

  • Posted by zoltan.herczeg at 04/29/2009 - 08:32

There was a time, when Internet Explorer ruled the word, and browser developments were nearly stopped. Fortunately, Mozilla Foundation has brought us the Firefox and big waves appeared on the silent ocean. A fierce war has started since then: both in terms of speed and features. After some time other big names joined like Apple and Google. Using these new tools, the human creativity has changed the internet into a rich and beautiful place. (OK, it has dark sides as well).

Which is better: tracking the register allocations or jumping freely in and out of the code.

  • Posted by zoltan.herczeg at 04/29/2009 - 12:06

NanoJIT is developed as a sub-project of the Tamarin ActionScript virtual machine. It is a lightweight JIT compiler, which produces machine code from a Low-level Intermediate Language (called LIR). LIR instructions are inspired by Register Transfer Languages. Furthermore, NanoJIT has already been ported to several architectures like x86, ARM and powerpc. However, SquirellFish Extreme, the JavaScript jit compiler of WebKit has taken another approach.

Technical discussion part 1: interface between jit and C++

  • Posted by zoltan.herczeg at 04/30/2009 - 12:16

Perhaps one might think that this topic is not a big deal. We have a guideline, called ARM-EABI (Embedded Application Binary Interface). Among other things, this paper specifies which registers must be preserved, how the stack must be handled, etc. We just have to follow these rules, don't we?

How big is that performance gain after all?

I have a quite fundamental problem... Let's assume that I came up with a bright new idea how to speed up the execution of JavaScript programs. Once implemented, of course, I'd like to measure it's effect and present the results to the world.

There are benchmark suites that exist exactly for this purpose. Now, if it takes 100 seconds for the unaltered JavaScriptCore to execute the whole SunSpider benchmark, and this drops to 77 seconds with my improvements applied, then what should I report?