Following up on part one of this series last week, here’s another
for more than four years). This week we’re going to look into an optimization called Function Context Specialization,
The name is a bit misleading. What it essentially does is to allow TurboFan to constant-fold certain values when
generating optimized code, and it does that by specializing the generated machine code for a function to its surrounding
context (which is V8 speak for the runtime representation of scope).
It’s been a while since my last blog post, mostly because I didn’t really have the time or the energy to sit down and write up all the stuff that I wanted to write about. Part of it was because I have been pretty busy with the Ignition and TurboFan launch in Chrome 59, which fortunately was a huge success thus far. But also partly because I took some time off with my family. And last but not least I went to JSConf EU and Web Rebels, and at the time of this writing I’m at enterJS, procastinating on doing the final tweaking for my talk.
February has been an exciting and very, very busy month for me. As you have probably heard, we’ve finally announced that we will launch the Ignition+TurboFan pipeline in Chrome 59. So despite running late, and not making it for February actually, I’d like to take the time to reflect on the TurboFan tale a bit, and tell my story here. Remember, that everything you read here is my very personal opinion and doesn’t reflect the opinion of V8, Chrome or Google.
Following up on what I promised earlier here’s another edition on what’s going on
behind the scenes of V8 as we are approaching the end of the year. A lot of cool stuff happened in V8 in 2016, probably most importantly
that we are changing the focus of V8 to treat Node.js as a first class citizen (similar to Chrome) and moving away
to measuring actual performance of real world web pages via tooling built into the browser.
here are a couple of comments I’d like to address. First of all, I’m over-exaggerating quite a bit with the intention to actually
is certainly not the only important technology in software engineering these days, there are many important technologies that have
comes to software engineering. To many of us who have been into programming languages, compilers and virtual machines for some time, this still
point of view, nor does it have a great standard library.
becoming the dominant technology on the server-/cloud-side (via Node.js), and even finding its way into the IoT space.
So this is my attempt to start a series of blog posts about what’s going on behind the scenes of V8 in order to bring more transparency to what we do for
Node.js and Chrome, and how this affects developers targeting either Node.js or Chrome. I’ll
a few tooling/embedder related issues.
For the last couple of months we - together with some awesome Ember folks - have
been hunting a terrible bug in V8, that I used to call “the Ember issue”, because this bug especially affects
websites based on the Ember.js framework. Ember.js was never really great in Chrome - i.e. there have been reports of serious
performance problems in 2013 already, when I had just joined the V8 team - but it seems like
it got worse recently, leading to increased load time and pretty serious jank - up to two second pauses - even though we spent a lot of resources
on techniques like the Idle-Time Garbage Collection Scheduling and
other jank related
improvements that should avoid exactly these problems.