Cross-compiling QtWebKit for Windows on Linux using MinGW

In this post I'll show you how to configure and compile a MinGW toolchain for cross-compilation on Linux, then how to build Qt using this toolchain and finally compile the Qt port of WebKit from trunk.

QtWebKit cross compilation with GCC for ARM-Linux

When I tried to cross compile QtWebKit for ARM-Linux, I didn't find any clear description, so I have decided to write a blogpost about it. It's not too hard, but if you have never done something like this, it can be a little bit confusing. In this post, I will describe this method in some simple steps.

What are JavaScript and SVG good for? - Built-in Flash engine?

There is a very interesting open source project: a Flash runtime engine written in JavaScript, called Gordon, written by Tobias Schneider. Although the project is still under development, you can get the first impressions how strong the JavaScript and SVG technologies are nowadays.

Compiling QtWebkit with RVCT for ARM-Linux

There are a lot of make specifications in Qt, but none of them is suitable for RVCT compilation. So, if you want to compile QtWebKit with RVCT, you have two options: either you create a new specification or you can use an existing one with wrapper scripts. In this post I'll describe the second option.

WebKitGtk+ cross compilation for ARM

WebKitGtk+ cross compilation consists of two parts. First, you need a cross compiler and the library dependencies of WebKitGtk+. Next, you have to setup the build system properly. You can reach this with some wrapper scripts.

Aim, shoot, weigh! - hunting for samples in the forest of JIT

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?

War of allocators: TLSF in action

The main focus of my next experiment is yet another allocator called TLSF (Two-Level Segregate Fit). Based on the info published on its website, TLSF has bounded response time, efficient allocation methods which are fast enough, and it has efficient memory usage. Furthermore, the site promises quite good memory fragmentation values. Can it demonstrate all this inside WebKit?

War of allocators: hoard or hoards?

I found Emery Berger's allocator called hoard. Hoard's homepage holds out some promising general qualities (fast, scalable, and memory-efficient) about the allocator, do we need more than this? I tried out how it performs in WebKit.

War of allocators: The QtLauncher's coast

After I benchmarked JavaScriptCore with our new participant called DLmalloc, it has been suggested to test it with QtLauncher also. I compiled DLmalloc in thread-safe mode (USE_LOCKS=1), so it became capable to serve WebCore's memory requests. Perhaps, another solution could have been to turn off every use of threads in QtLauncher/WebCore, but I think this would be a lucky approach...

Comparing JSValue representations in JavaScriptCore. A short overview.

  • Posted by zoltan.herczeg at 02/25/2010 - 14:43

The central data structure in JavaScriptCore is JSValue. It represents the value of a JavaScript variable. Since there are no type restrictions in JavaScript, a JSValue can contain anything from a simple bool constant to an object. Most operations work on these JSValues, so their effective handling is essential for a fast JavaScript engine. In JavaScriptCore there are 3 types of JSValue representations: JSValue32 and JSValue32_64 for 32 bit machines, and JSValue64 for 64 bit machines. Albeit maintaining all of these representations is a heavy burden, the feeling to have a fast JS engine is rewarding.