Skip navigation.

Log in | Sign up

Opera Core Concerns

Official blog for Core developers at Opera

Carakan Revisited

A little more than a year has passed since we launched the Carakan project, aimed at drastically improving Opera's ECMAScript execution performance, and it's finally time for the first labs release of Opera with the Carakan ECMAScript engine.

What we set out to implement over a year ago was, as I described in a previous post about the Carakan project, a new cross-platform bytecode interpreter for a new register-based instruction set, a new internal object model with automatic classification and inline property caching, and machine code generation. All this we've done, and then some.

The new bytecode interpreter and new object model are cross-platform, meaning they will work on any hardware platform Opera is ported to. On their own, they already give a significant performance boost compared to Futhark, the engine used in all current versions of Opera. Running on a regular desktop computer, Carakan's bytecode interpreter is around 3.5 times faster than Futhark on the Sunspider benchmark, and on embedded systems running less powerful CPUs early testing shows it to have an even greater advantage over Futhark.

For optimum performance, however, machine code generation, or JIT, is the way to go, and this is where we have focused most of our optimization work. Carakan is equipped with a hot-spot detecting JIT compiler that generates machine code that performs all but the most complex operations directly without calling the bytecode interpreter. It employs a combination of compile-time static analysis of the program and runtime profiling in the bytecode engine to optimize the generated code, focusing in particular on code that does arithmetic calculations. It also performs function inlining, both of simple built-in functions such as Math.sqrt() and String.charCodeAt() and of functions implemented in the script. Currently the JIT compiler only supports generating 32 or 64 bit x86 machine code, but support for other architectures will be added in time, starting with the ARM architecture.

But this is not all we have done in the Carakan project. I'd like to also mention two other interesting improvements that we've implemented compared to Futhark: a divided garbage collected heap, and caching of compiled scripts.

Divided garbage collected heap

The ECMAScript language assumes the presence of a garbage collector that automatically reclaims memory occupied by objects that are no longer needed. Carakan's garbage collector is very similar to the one used in Futhark, a basic mark-and-sweep design; we've only done some smaller, but rather effective, tweaking of its performance. We have however drastically changed how we use the garbage collector. In Futhark, all memory allocated by the ECMAScript engine for scripts running in any tab was allocated from a single shared heap, and anytime the garbage collector needed to run to free up memory, it would traverse all allocated memory. The more open tabs there were, the more expensive would a garbage collection become.

In Carakan, we instead use many smaller heaps. Each document loaded in a tab, or in a frame or iframe inside another document, gets its own. Since scripts running in different documents can sometimes access each other's objects, we have support for merging two heaps into one, and for detecting when this is necessary. The advantage of this design is clear: with smaller heaps, each garbage collection is cheaper. And since we only need to run the garbage collector on heaps from which memory has been allocated, we automatically only traverse the memory of active heaps, and leave all other heaps alone. The end result is that it doesn't matter if there are 1 or 100 open tabs; when a script triggers a garbage collection, the cost is the same.

Cached compiled programs

An aspect of an ECMAScript engine that performance benchmarks often don't measure is the performance of the compiler. Compared to Futhark, the Carakan compiler is much more focused on analysing the program and generating code that will execute fast, and may therefore be slightly slower in some cases. This is a trade-off we've made willingly.

Instead of the very efficient compiler in Futhark, Carakan brings caching of compiled programs. In practice this means that whenever a script program is about to be compiled, whose source code is identical to that of some other program that was recently compiled, we reuse the previous output from the compiler and skip the compilation step entirely. This cache is quite effective in typical browsing scenarios where one loads page after page from the same site, such as different news articles from a news service, since each page often loads the same, sometimes very large, script library.

Plans for the future

Although we're nearing the release of the Carakan engine, we don't plan to stop development of it. We have plenty of ideas on smaller and larger improvements to make, and we will also port the JIT compiler to other CPU architectures.

One area where we believe we can improve greatly is in memory usage, by switching to a much more efficient object representation. Carakan will already today use less memory than Futhark in some cases, by sharing information between similar objects via the automatic object classification system and by sharing literal data using a copy-on-write scheme, but we have plans that would reduce the size of ECMAScript objects to as little as a tenth of their current size.

We will also be looking at improving the performance of machine code generated for non-arithmetic code such as property accesses, where our JIT compiler currently produces significantly less stream-lined code than it does for arithmetic calculations.

Native JSON support in Opera


Ken Rushia 22. December 2009, 07:56


zikzakatak 22. December 2009, 07:59

thanx a lot for this info...

Adrien 22. December 2009, 08:10

Sounds nice especially for the "Cached compiled programs".

d4rkn1ght 22. December 2009, 08:31


Ian Doyle 22. December 2009, 08:45

I saw "and it's finally time for the first labs release of Opera with the Carakan ECMAScript engine." And got way too excited...thought we might get an early Christmas present. :smile:

Royi 22. December 2009, 10:16

Those are great news.
How is it compared to V8, Nitro?

Performance is the main feature I chose browser by.
Carakan might bring me back to Opera.

Purdi 22. December 2009, 10:20

Originally posted by Drazick:

How is it compared to V8, Nitro?

Carakan is the fastest engine right now.

ritmocafe 22. December 2009, 10:30

WOW! Do opera put you guys on steroids at work?

bachokocho 22. December 2009, 10:32

Originally posted by Purdi:

Carakan is the fastest engine right now.

Purdi, would you post some data! My observations show that it has the qualities but needs polishing :smile:

Purdi 22. December 2009, 11:07

Originally posted by bachokocho:

Purdi, would you post some data! My observations show that it has the qualities but needs polishing

No, it's definitely faster. Try Sunspider. Ignore the V8 benchmark as it's crap, by the way. Google loves cheating.

Daniel James Hendrycks 22. December 2009, 12:46


Pallab De 22. December 2009, 13:51

Most of it was greek to me, but I enjoyed reading it anyway.

Originally posted by bachokocho:

Purdi, would you post some data! My observations show that it has the qualities but needs polishing

You can find some data here. Opera is now indeed the fastest browser. It feels really nice, since Opera was always known for its speed.

Teo 22. December 2009, 15:12

If I remember correctly, Lua 5.0 has employed a register-based VM since 2003 and it consistently held the crown as the fastest script language since then. I was mildly shocked to learn that Opera haven't used this idea till now.

I've always liked Opera for the comfort it gives me with its thousands of little helping functions but I would not turn down a faster js engine. Keep up the good work, we expect nothing less than technical marvels from you, guys and gals!

Bruno Casano 22. December 2009, 16:12

Great article !!!! Even more incredible release !!! WOOW great job guys !!!! :D

Happy holidays !!!

Pallab De 22. December 2009, 18:28

Originally posted by umbra-tenebris:

I've always liked Opera for the comfort it gives me with its thousands of little helping functions


Cutting Spoon 22. December 2009, 18:54

@Teo: For that matter, some Perl implementations have used partial compiles from the beginning of the language. Java and JavaScript are managed-code specifications for cross-platform use. I've mostly only seen the simplified MurgaLUA, and then only under Linux. For that matter both Ruby and Python have made strides in JIT, and .sh objects continue to become ever more efficient. A custom, cross-platform JavaScript engine with on-the-fly transcoding is a big deal. Jens Lindström stated that Carakan can generate native x86 and x86-64, with plans for ARM and other platforms soon (GP-GPU?). I don't know if any other browser's JIT implementation has gotten to the matter of non-x86 platforms yet; possibly Fennec or the ChromeOS for ARM platforms?

I am very grateful for this candid disclosure of new features and limitations; looks like Carakan has a great deal of potential. If Opera can deliver on CPU savings and reduced memory requirements with JIT, then Opera Mobile with JIT will be extraordinarily capable. 3x-5x CPU efficiency and up to 10x memory efficiency would allow ANY modern JS/Gears-based site to run on a smartphone.

vikyboss 22. December 2009, 19:49

Keep up the work, develop the engine. Update it often and thats the way Opera can get good. Thanks for the first superb build..

Teo 22. December 2009, 20:20

It seems you misunderstood me. I consider Carakan to be a marvelous technical achievement. I was surprised that Futhark is that speedy without using a registered vm.

Daniel James Hendrycks 22. December 2009, 23:10

:up: Fearphage?

Charles Schloss 23. December 2009, 01:38


Ice Ardor 23. December 2009, 09:07

Thanks for the details. I've been kinda curious how the "new engines" are being produced.

Jim 24. December 2009, 03:19

@Pallab De: What kinda system are u running? The V8 bench gives me a score of 2300-2500. Also you should compare the V3 and V4 of SRWare Iron next time, they generally run a little faster than Chrome has a nice article on the recent betas

Write a comment

You must be logged in to write a comment. If you're not a registered member, please sign up.