Clearing caches on system signal

  • Posted by balazs.kelemen at 07/06/2009 - 12:28

Currently, I'm experimenting with WebKit to release all the memory what we can on given conditions. This can be useful in low memory situations or when the system goes asleep (less RAM usage needs less power).

Ever wanted to compare different JIT engines? Now that is possible!

It is well known that runtime profiling is handy when we want to measure the runtime cost of different functions, identify the performance bottlenecks of the code, or measure the progress of the project over a period. However, most profiling mechanisms are tied to a specific project, which makes the comparison of different solutions impossible. I have developed a simple library, which can easily be added to any existing JIT engine. The attached tgz contains patches for wide-spread JIT engines (namely WebKit-JavaScriptCore and Tamarin-NanoJIT).

Technical discussion part 3: property caching madness in JIT

Dynamic languages like JavaScript have a lot of interesting fetures: we can create or destroy new classes during runtime or assign anything to any variable regardless of its type. These features makes them popular and since computers are getting faster, more and more tasks are performed by these languages. The fact that a language is dynamic does not necessarily mean that programs written in it have to be slow. Perhaps they will never be as fast as a compiled language, but there are some nice optimization algorithms for them. Those algorithms are different form static compiler optimizations.

Technical discussion part 2: constructing constants

  • Posted by zoltan.herczeg at 05/18/2009 - 10:19

Among other things, one interesting advantage of dynamically generated code is that constants can be embedded into the instruction stream. Think about it: there are several constants (usually pointers), which are unknown at compile time, but behave as constant once a value is assigned to them. Those constants can be embedded into the generated code, so several load-from-memory operations can be eliminated. WebKit JIT goes one step further: you can also rewrite constants which are not even known at JIT compilation time. Those constants typically hold cached values used by some fast cases.

Memory consumption: scratching the surface

  • Posted by zoltan.horvath at 05/13/2009 - 11:06

On Linux platform, WebKit doesn't provide us with tools/scripts for investigating memory consumption, although this topic might be almost as important as runtime performance. For example, just think of an embedded environment where memory is limited and the usage of memory has an impact on the device's power consumption.

Nitro-Extreme on ARM. What happens to nitro during extreme conditions?

Recently, a new branch has appeared in the WebKit trac, called Nitro-Extreme. I know the work has not been finished yet, but it never hurts to take a look at the current revision.

ARM support for JavaScript engine of WebKit

  • Posted by gabor.loki at 05/05/2009 - 09:13

We have announced the ARM port of WebKit on webkit-dev mailing list in April. Additionally, a Bugzilla entry was opened for the technical discussion. After that we received several feedbacks which encouraged us to continue our work, but some feedbacks reported technical difficulties on getting and building our code. This post is going to summarize how to get and build the ARM port for your device.

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?

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?

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.