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.

A fast, custom-written parser for JavaScriptCore. Human creativity VS code generator.

Perhaps the first question to pop out of somebody's mind is why do we need a fast JavaScript parser? A browser does so many things, why do we focus on JavaScript parsing, which probably consumes only a small amount of time? Earlier, we were thinking alike, but oprofile yielded some surprising results. The JavaScript parser was often responsible for 15-20% of the runtime of libWebKit. Further analysis has shown that popular web-sites usually come with big JavaScript source files (about 200-400k). These JS files contain a lot of source code, many are brower-specific. The expensive operation here is the syntax checking of the whole source code, as the browser must reject the execution of invalid JS files.

War of allocators in JavaScriptCore: another participant

There are a lot of custom allocators in the world, so let's try another promising one, called DLmalloc. It was made by Doug Lea. I've put DLmalloc into JavaScriptCore with the help of the custom allocation framework. I tested DLmalloc only in JavaScriptCore, because it didn't work well with QtWebKit's multi-threaded features. The measurements have been made with QtWebKit, running on x86 Debian-Lenny.

 

War of allocators: The field of Workers

Since, two of our tested allocators - TCmalloc, JEmalloc - benefit in multi-threaded environment, I did some benchmark which uses threading effectively. I run 2 instances of each popular benchmarks simultaneously with the help of JavaScript workers. I benchmarked on Linux-Qt port of WebKit and used official r54475 revision. All measurements were running in QtLauncher and did minimal painting only.

War of allocators in JavaScriptCore

JEmalloc is a highly scalable memory allocator made by Jason Evans. This is the default allocator of the FreeBSD operating system and Firefox's Linux/Windows versions, but how does it perform in WebKit?

The sounds of TCmalloc in QtLauncher

It took a while but now I'm happy to announce that all core classes are inherited from FastAllocBase in WebCore. Further the previous changes in JavaScriptCore, by now almost the whole world is a subclass of FastAllocBase. :-)

Using bugzilla-tool

  • Posted by zoltan.horvath at 12/14/2009 - 13:34

Bugzilla-tool is a useful tool for managing bugzilla related activities. You can do many things with it, e.g., create bugreports from local trunk and apply patches to local trunk, land patches automatically. The only thing that you have to use is your command line... The tool is located in the WebKitTools/Scripts directory, but it has some requirements.

Progress of the Code Camp

  • Posted by akos.kiss at 12/09/2009 - 11:24

So, it seems that everyone survived the first day (and the night...) For those who are not here with us in Wiesbaden but are interested, here is a link where the progress of the camp can be followed. (Provided that people are not too lazy to upload content... :) )

QtWebKit Code Camp started

  • Posted by akos.kiss at 12/08/2009 - 15:09

Half of our team is now in Wiesbaden, Germany. We will stay here for 3 days and participate on the QtWebKit Code Camp. Quite a big bunch of people gathered here - more than 50 people from 3 continents (or more). It's great to have so many nicks here from #qtwebkit. And look, the nicks have faces! :)