Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

I’m going to start off by showing my favorite demo, that I think really captures what we’re enabling by making the browser as fast possible.

So this is Doom, translated - actually compiled - from C++ to JavaScript, being played in Firefox. In addition to JavaScript it’s using the new 2D drawing element called Canvas. This demo is completely native to the browser. There’s no Flash, it’s all open web technologies. And it’s managing to get a pretty good framerate, 30fps, despite being mostly unoptimized. This is a really cool demo for me because, three years ago, this kind of demo on the web was just impossible without proprietary extensions. Some of the technology just wasn’t there, and the rest of it was anywhere from ten to a hundred times slower. So we’ve come a long way.… Unfortunately all I have of the demo is a recording, it was playable online for about a day but iD Software requested that we take it down.

To step back for a minute, I’m going to briefly overview how the browser and the major web technologies interact, and then jump into JavaScript which is the heart of this talk.

This is a much less gory example, a major company’s website in a popular web browser. The process of getting from the intel.com URL to this display is actually pretty complicated.

The browser then sends intel.com this short plaintext message which says, “give me the webpage corresponding to the top of your website’s hierarchy.”

How does the browser get from all of this to the a fully rendered website?

Now that we’re familiar with the language’s main features, let’s talk about implementing a JavaScript engine. A JavaScript implementation has four main pieces

One of the challenges of a JavaScript engine is dealing with the lack of type declarations. In order to dispatch the correct computation, the runtime must be able to query a variable or field’s current type.

We’re done with data representation and garbage collection, so it’s time for the really fun stuff: running JavaScript code, and making it run fast. One way to run code, but not make it run fast, is to use an interpreter.

35.
Execution engine (VM)</li></li></ul><li>Values<br />The runtime must be able to query a value’s type to perform the right computation.<br />When storing values to variables or object fields, the type must be stored as well.<br />

41.
Too big! We have to pack better.</li></li></ul><li>Boxed Values<br />We could use pointers, and tag the low bits<br />Doubles would have to be allocated on the heap<br />Indirection, GC pressure is bad<br />There is a middle ground…<br />

56.
Garbage Collection<br />Need to reclaim memory without pausing user workflow, animations, etc<br />Need very fast object allocation<br />Consider lots of small objects like points, vectors<br />Reading and writing to the heap must be fast<br />

57.
Mark and Sweep<br />All live objects are found via a recursive traversal of the root value set<br />All dead objects are added to a free list<br />Very slow to traverse entire heap<br />Building free lists can bring “dead” memory into cache<br />

58.
Improvements<br /><ul><li>Sweeping, freelist building have been moved off-thread

59.
Marking can be incremental, interleaved with program execution</li></li></ul><li>Generational GC<br />Observation: most objects are short-lived<br />All new objects are bump-allocated into a newborn space<br />Once newborn space is full, live objects are moved to the tenured space<br />Newborn space is then reset to empty<br />

89.
Observations<br />Even though we have fast paths, no type information can flow in between opcodes<br />Cannot assume result of ADD is integer<br />Means more branches<br />Types increase register pressure<br />

177.
If VM breaks an assumption held in any JIT code, that JIT code is discarded</li></li></ul><li>Conclusions<br />The web needs JavaScript to be fast<br />Untyped, highly dynamic nature makes this challenging<br />Value boxing has different tradeoffs on different ISAs<br />GC needs to be fast – what should we focus on?<br />

178.
Conclusions<br />JITs getting more powerful<br />Type specialization is key<br />Still need checks and special cases on many operations<br />