“The Web is a changing environment, however, and tomorrow’s advanced Web applications will require faster ECMAScript execution, so we have now taken on the challenge to once again develop the fastest ECMAScript engine on the market,” he said.
“This move is more about preparing for the future when we’ll see more complex Web apps that use the Web browser as the application platform — as we see more software development based on Web technology,” Bolstad said.
Improving On the Previous Engine
Meanwhile, Lindstrom said the Opera team has focused on improving on the previous engine in three main areas: register-based bytecode, native code generation and automatic object classification.
According to Lindstrom, the last couple of generations of Opera’s ECMAScript engine have used a stack-based bytecode instruction set. However, said Lindstrom: “In the new engine, we’ve instead opted for a register-based bytecode instruction set. In a register-based machine, instead of a dynamically sized stack of values, there’s a fixed size block of them, called ‘registers.’ Instead of only looking at the values at the top of the stack, each instruction can access any register. Since there is no need to copy values to and from the top of the stack to work on them, fewer instructions need to be executed, and less data needs to be copied.”
In terms of native code generation, to eliminate the overhead involved in executing simple ECMAScript code, Opera is implementing compilation of whole or parts of ECMAScript programs and functions into native code.
“This native code compilation is based on static type analysis (with an internal type system that is richer than ECMAScript’s ordinary one) to eliminate unnecessary type-checks, speculative specialization (with regards to statically indeterminate types) where appropriate, and a relatively ambitious register allocator that allows generation of compact native code with as few unnecessary inter-register moves and memory accesses as possible,” Lindstrom said.
In addition to generating native code from regular ECMAScript code, we also generate native code that performs the matching of simple regular expressions, he said.
“The other area of major improvement for Carakan over the current engine is in the representation of ECMAScript objects,” Lindstrom said. “In the new engine, each object is assigned a class that collects various information about the object, such as its prototype and the order and names of some or all of its properties,” he added. “Class assignment is naturally very dynamic, since ECMAScript is a very dynamic language, but it is organized such that objects with the same prototype and the same set of properties are assigned the same class.”
Meanwhile, Lindstrom said the name Carakan, like the names of Opera’s previous ECMAScript engines, Futhark, Linear A and Linear B, is the name of a writing system, or “script.”
Opera announced Carakan at the Web Directions North conference in Denver. Also at that event, Opera announced Vega, a new vector graphics library.
In a blog post, Opera developer Espen Andre Overdahl said Opera built Vega after the company began working on SVG support, which required a vector graphics library.
“We looked into what libraries were available to use and met our requirements — fast, low memory usage and working on platforms ranging from phones to TVs and desktop computers,” Overdahl said. “We did not find a good match for our needs, so we decided to write our own. Shortly after we created Vega we also added Canvas support.”
Overdahl said the most recent addition to Vega is the ability to use a hardware-accelerated back-end. And Opera is currently using OpenGL and Direct3D, he said.