
Inside JavaScriptCore's low-level interpreter - p4bl0
http://wingolog.org/archives/2012/06/27/inside-javascriptcores-low-level-interpreter
======
acqq
In short: in order to write the fast interpreter for the bytecode of
JavaScript in WebKit JS's JavaScriptCore, the author developed a custom
variant of an assembly language, wrote the interpreter in it and wrote in Ruby
the translator from his custom assembly to the native assembly (allowing him
to target different processor architectures like x32 x64 and ARM, at least
that's how I understood it from the description).

He explains how with C++ he could not get the speed gains he achieved with
assembly. One real life example where writing exact assembly code still
matters.

Coming to a browser near you.

~~~
wingo
No offense intended, but this comment does not add very much while
misunderstanding some other things. For example, I did not write the LLInt. It
was mostly written by Apple's Filip Pizlo.

If this is the sort of topic you are interested in, then you can have the
patience to read a few paragraphs. If it's not, then summarizing isn't going
to help :)

~~~
acqq
Thanks, now I know that LLInt (the new interpreter) was written by Filip
Pizlo. Note that you mention him in the article only related to DFG JIT. I
didn't try to investigate the source files or checkins, I tried to understand
only what you write, and that was obviously not clear enough.

I hope you see that I'm interested in the topic but read about it the first
time. I hope you also can imagine that there are more readers like me. And
they would benefit from the correct summary too.

Please do write what else I misunderstood, that is exactly the reason why I
wrote the short summary, to get the feedback, not to claim that I understand
more than you or any insider. It's short, counting the words some 20 times
shorter than your article, so I hope it wouldn't be hard for you to point to
any other inconsistency. Summarizing helps if the result is something relevant
and clear, in a few sentences instead of 1700 words. Without the summary, the
most important points can be overlooked/misunderstood by anybody not "close to
the sources."

~~~
wingo
Well, I guess the one thing I would correct is the "why". The LLInt doesn't
just produce assembler to be fast, though it is faster than the old
interpreter. The real reason it produces assembler is to control the stack
representation, so that it works better with tiering, exceptions, and the
optimizing compiler (DFG). Otherwise, interpreting was a lose, because tiering
up cost too much.

As you can see, the situation is a bit complicated. If I could have made the
article shorter, I would have :)

~~~
acqq
Thanks, I understood that the main benefit was a tightly controlled CPU stack
and that it's exactly what would be impossible to achieve with C++ code. Now
we don't have to agree if that goal can be called "speed." I believe it can,
since otherwise just a "good old" interpreter would be enough, no need for
"simple JIT," DFG JIT and the control of the CPU stack.

And thanks for writing the article (and the other ones on the same subject)
I've really learned a lot!

------
acqq
For those who don't know JavaScriptCore under that name:

JavaScriptCore, the WebKit JS implementation
[http://wingolog.org/archives/2011/10/28/javascriptcore-
the-w...](http://wingolog.org/archives/2011/10/28/javascriptcore-the-webkit-
js-implementation)

"In 2008, the WebKit folks (...) called the thing SquirrelFish Extreme.
_Marketers called this Nitro Extreme._ (Still, the proper name of the engine
is JavaScriptCore; Wikipedia currently gets this one wrong.)"

<http://en.wikipedia.org/wiki/WebKit#JavaScriptCore>

"JavaScriptCore is a framework that provides a JavaScript engine for WebKit
implementations, and provides this type of scripting in other contexts within
Mac OS X."

Probably should be "within Safari browser." But as the first linked article
notes:

"JSC folks were doing great, well-factored work. It was so good that
SpiderMonkey hackers at Mozilla adopted JSC's regexp JIT compiler and their
native-code assembler directly."

I believe then it should be "as the whole within Safari browser, and some key
parts also within Firefox browser."

~~~
chc
What is it you think should say "within Safari browser"? JavaScriptCore is
certainly not inside Safari; it's a part of WebKit. JavaScriptCore is no more
"within Safari" than WebKit itself is. But I'm not sure what else you could be
referring to.

~~~
acqq
The Wikipedia article, at the moment I quoted from it related to Max OS X but
not mentioning Safari at all, and Safari runs on other platforms: iOS and
Windows."

Moreover the conclusion that "the JS engine is used wherever WebKit is used"
would be false. Wwhen describing the use of the given engine, it's not a good
description to say "the engine in WebKit" as there is an example of the very
popular use of WebKit without the engine: Google Chrome.

~~~
chc
Neither I nor Wikipedia said "used wherever WebKit is used". The Wikipedia
article said "JavaScript engine for WebKit implementations" and I said "part
of WebKit". The fact that Chrome chooses not to use it is immaterial. It is
part of WebKit. Check out the WebKit source and you will get the
JavaScriptCore source as part of it.

Similarly, there's a GIMP-based image editor called Seashore that doesn't use
a lot of GIMP's UI, but I still think it's fair to say that the UI code is
part of GIMP.

