V8: Chrome's JavaScript engine source code | Hacker News Reader

V8: Chrome's JavaScript engine source code

code.google.com

48 pointsmace20 comments

It is obvious that the "older" JS-engines were not built for executing applications, but more for running small in-expensive things on homepages. As of the later years, JS has become pretty heavy and people use it a lot more.

The genius here is to recognize that most of the cool work done to Smalltalk and Self applies equally well to Javascript. It feels like cheating, but the V8 team is actually just picking some low-hanging fruit done with research in the 90's. They push the envelope for what we can use JS for and that is a really good thing!

Now this runs a lot faster:

http://www.abrahamjoffe.com.au/ben/canvascape/

There are now three engines vying for the title of the "fastest" JS engine:

* Tracemonkey (Mozilla) * Squirrelfish (Apple/Webkit) * V8 (Google)

I would love to see a benchmark comparison (Sunspider?) to see how V8 compares to Tracemonkey and Squirrelfish.

And let's hope this pushes MS into the race.

Or, completely out, perhaps? I mean, the race has been going on for a bit, now.

IE isn't going away, so I think its in everyone's best interests that they are actively involved in the browser competition.

Why so sure it's not going away?

Put yourself in their shoes and attempt to come up with one good reason why they wouldn't want to keep making a browser. They rarely get out of markets they're already in, and I don't think they're just going to forfeit a dominant market position just because the competition is better (see Windows).

IE as an application is definitely here to stay, but I wouldn't consider it too off the wall for them to switch to one of the OSS HTML / JS engines. I don't expect it, but it wouldn't surprise me.

I didn't say they'd stop making a browser, I'd suggest people will just stop using it.

If they do their classic strategy, it'll be "embrace and extend" with Javascript. The only problem is that their marketshare has eroded to the point where this might just cause their marketshare to erode even more.

Where does Tamarin land in this? They're working with Mozilla too, aren't they?

Tracemonkey adopted ideas and pieces of Tamarin.

I found a blog entry with some SunSpider runs: http://web-graphics.com/2008/09/02/scripting-engines-just-go...

Unfortunately a TraceMonkey bug prevents direct comparisons.

Brendan Eich posted some new numbers with a more recent TraceMonkey build.

http://weblogs.mozillazine.org/roadmap/archives/2008/09/trac...

I'd bet V8 is a definite improvement over Tracemonkey. It really feels like V8 already improves the DOM manipulation/property getters/setters for DOM. Mozilla doesn't plan to do that until past 3.1!

(Just find a site that has a lot of complex windows. Fastest link I could find: http://extjs.com/deploy/dev/examples/desktop/desktop.html )

It probably feels faster because WebKit is really good about DOM manipulation. A lot of people don't seem to realize that the lion's share of time for a lot of JS stuff is in manipulating the DOM and re-rendering the page.

Coupling an advanced javascript compiler/vm with a really quick rendering engine leaves you with what you feel there.

Hard numbers, V8 is maybe 3x faster than WebKit nightlies on every benchmark suite I could find.

I have been grepping through the tree trying to find the implementation of the String class. A part of me thinks they just defined it in string.js and somehow made the rest of the code treat it as a cpp class.

it is not uncommon to patch primitives into your language by having special "__primitive" or something such annotations which can be added to call over a language barrier. In this case, you would annotate certain Javascript functions/classes so they refer to their C++ equivalent code.

You gain the advantage that the difference between library code and primitive built-in things blur more so one function can be implemented as a javascript function (because the compiler already produces good code for that part), while another function (un-implementable in JS) is C++.

I think (fuzzily), from what I can find, that string-stream.cc allocates a block of char's for a string. Once the string grows beyond the capacity, `char* HeapStringAllocator::grow(unsigned* bytes)` doubles the size of the allocated buffer. Kind of disappointing after half an hour of reading and C-s'ing in Emacs.

`string.js` is used by `tools/js2c.py` to create a `string.h`, but otherwise I think many of the string functions are implemented in JavaScript and (I'm guessing) compiled later since `string.js` and other JavaScript files are referencing C macros.

Reply on news.ycombinator.com