
V8 under the hood - davidw
http://offthelip.org/?p=113
======
stcredzero
_When you build V8 from source, you can have it generate a snapshot of the
memory state once the libraries are loaded and this gets packaged in the
executable. It makes it slightly bigger but the load time is blazingly fast.
Pretty sweet._

That's like the Smalltalk _image_! (A few years ago, a 10 megabyte VisualWorks
image could load faster than the 768k Perl runtime.)

~~~
catch23
The cool part about that is maybe they could precompile stuff like prototype,
jquery, etc and include it with chrome since majority of websites use some
kind of framework. All it would have to do is run a checksum on the prototype
js file and if it matches, load a precompiled version.

Then again, it probably wouldn't help too much, since most websites employ
fancy packaging tricks to speed up javascript file load times.

~~~
litewulf
Or more generally... I've been hearing about these things called caches...

Maybe they should "cache" this data for the most common files. Voila, no
favoritism, only sweet sweet performance. (At the cost of having some sort of
frequency table.)

And cache eviction and all that is pretty well understood too...

~~~
eggnet
But you don't know that url A and url B in fact point to the same file until
after the file has been downloaded. At that point, why not just load the
javascript instead of performing an md5 checksum.

~~~
litewulf
Because parsing isn't free. In addition, one interesting optimization it opens
up is something akin to the JVM where performance improves as profiling of
code is done. Imagine if every site that used a Javascript library served to
improve the performance of that library for all future invocations. That would
be nifty.

------
procrastitron
I have to wonder why they chose C++ for writing the VM. Since their
architecture is based on compiling Javascript, why not just write the compiler
in Javascript to begin with?

The most likely reason I can think of is that it makes it easier to interface
with the existing WebKit code, but this doesn't seem like a very strong reason
to me.

~~~
orib
Because you would need to bootstrap it every time you want to run it, since
Javascript is interpreted. This means you'd need a 3rd party Javascript
interpreter to run your Javascript interpreter.

~~~
wmf
You only need to bootstrap it once and write out an image.

~~~
orib
Ah. So you propose writing a Javascript compiler that spits out a dynamically
linkable, PIC executable for multiple architectures using semi-static
assembly, and then using that to write V8? Otherwise, if you simply dump a raw
image you've got a closed environment that can't really be integrated into a
browser very well, or linked into other apps for their use.

That's a whole lot of unnecessary -- and nontrivial -- work, when all you want
to do is interpret Javascript.

~~~
wmf
I'm not really _proposing_ anything, since the V8 team has forgotten more
about VMs than I know, just pointing out another common design alternative.
The post implies that V8 can already perform some sort of AOT compilation:

 _When you build V8 from source, you can have it generate a snapshot of the
memory state once the libraries are loaded and this gets packaged in the
executable. It makes it slightly bigger but the load time is blazingly fast._

There's certainly extra work in this approach, but maybe it would be worth it
if it allows the compiler to be written in a more productive language.

------
jwilliams
This is interesting - No intermediate language. I was wondering about this in
response to a comment yesterday: <http://news.ycombinator.com/item?id=293962>

This linked to a post where one of the key developers (Dave Griswold) said
"The release of the V8 VM is the beginning of a whole new era for dynamic
languages"...

From this, I wouldn't see this as the case at all. I can't imagine many people
wanting to use JavaScript as an intermediate language.

Without an intermediate language or some form I wouldn't call this a Virtual
Machine - it's an interpreter... Granted, a pretty fast and sophisticated one.

~~~
jrockway
Actually, it's more like a compiler than an interpreter. I think people use
the term "VM" out of ignorance -- they think VM is a fancy term for "thing
that runs javascript".

But anyway, if you want to run your $NEW_LANGUAGE on V8, just compile your
language to JavaScript. That is the "IR".

------
bradgessler
Has anybody taken a shot at building a js server stack that can intelligently
detect the capabilities of the user-agent, and determine what code can be
executed client-side and what code can be executed on the server?

~~~
felipe
Not sure about detecting the capabilities of the user-agent, but Aptana did a
quite interesting server-side Javascript implementation:

<http://www.aptana.com/jaxer>

Interestingly enough, server-side Javascript is actually quite old. I remember
one of the very first web apps I worked with was in SSJS (aka Server-Side
JavaScript), on the Netscape Enterprise Server.

~~~
bradgessler
I remember ASP 2.0/3.0 supporting server-side js! I've never seen anything
though where you write the js code once, and the server determines where to
execute the code.

