Web Apocrypha

Many people are using OProfile for system measurements on Linux. This is a very handy profiling tool (supports hardware performance counters and has a very low runtime overhead) although it is in alpha phase. Using OProfile to measure any application performance is a straightforward task on Linux: you should get the latest OProfile for your machine or device, build, configure and run the daemon, and start measuring an application or your whole system. Finally, you can execute several scripts which report the performance numbers to you (according to your reporting requests). It sounds easy, doesn't it?

There was a post about Nitro Extreme some time ago on this site, so it is time to recollect what happened so far. Nitro Extreme is not a branch anyomore, it went to mainline, and replaced the old JavaScript Value (JSValue) representation on 32 bit machines. To be more precise, it happened only on x86.

Much time has passed since we started to work on the custom allocation framework with Paul Pedriana. The core of the solution (FastAllocBase class, bug #20422) was landed into the trunk half year ago.

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.

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.

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.

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?

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.

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).