Foundation

My fixation, passion, and preoccupation with the garbage collection led to this new blog post aptly titled V8’s Juice. Chrome is the forerunner in browser innovation war and which is not only altering the way we browse the WWW (world wide web) but also the way we develop applications that run inside the browser. We have talked in the past about different flavors of GC (link), please read and brush up the fundamentals of GC before diving deep into this article. 

V8

What is V8? V8 is the chrome browser’s javascript engine that acts as an interpreter and as well as, provides an execution runtime environment for the javascript. We are not going into the interpreter part, as it deems a separate article. But, thoroughly dig into the GC that V8 is supporting. The terminologies you need to be familiar here are as following: Reachable vs Unreachable nodes, GC generational hypothesis.

How V8’s GC is different?

V8’s juice is concentrated in the silky smooth experience that it tries to achieve without Janks during pauses by running GC idle time scheduling algorithm. Let’s dissect that statement and take on one at a time. 

What is silky smooth without Janks? 

The browser is innately single-threaded; the browser renderer (CSS+HTML parser = Layout) + execution of Javascript + GC all run on one single main thread. Though modern versions of chrome support concurrent multithreading (link). By default, JavaScript blocks DOM construction and thus delays the time to first render. With that said, lets talk about Frames in rendering process-once the layout is done we need to draw the boxes of DIV, SPAN, BODY, IMAGE, INPUT, etc, in the browser viewport (the visible area in the screen) using the low-level rasterizer API (convert an image stored as an outline into pixel format that can be displayed on the screen). This creates frames of rasterized data which is fed to the viewport screen every second. The approved rate is 60FPS(frame per second). If we by error or by accident go producing fewer frames (say for eg 50FPS), there is a high chance of missing frames and hence there is not so the silky smooth experience for the viewer which is described here with the new terminology coined as “JANK”. This degrades the experience. Also another important thing to note is 60frames/sec means 1/60 = 0.01666seconds. This means that 1 frame should be delivered within the threshold of 16.6 ms. This also means that all the rendering + JS should be performed (for silky smooth jank free experience) and running GC within 16.6 ms. Isn’t that a challenge? I am pleasantly awestruck at the level of minute gritty engineering that goes into chrome’s V8.

What is idle time GC? 

Generically speaking the GC takes a hit on the performance(even-though it’s in ms) of any application that it monitors in identifying live memory, freeing unused memory, and compacting fragmented regions of memory, even when employing concurrent garbage collection. Can a browser running webpage take that hit and still give a smooth experience? I don’t think so? That’s where chrome team came with this idea called as idle time GC. You see the figure below-there are a series of tasks like ‘input’,‘draw’ etc in the first chunk of activity, which need to be performed in 16 ms timeframe. That said, the idle period where there is an opportunity to run the GC and other tasks.

There are three key challenges for the garbage collector to efficiently take advantage of idle tasks. 

1. Which garbage collection operation should be scheduled during idle time? Like (identifying live memory, freeing unused memory, and compacting fragmented regions of memory, etc).
2. How long will a given garbage collection operation take? V8 can proactively estimate with heuristics and squeeze the GC actions inside the idle task within the threshold.V8 marks live objects incrementally in many small steps, pausing only the main thread during these marking steps. When incremental marking is completed the main thread is paused to finalize this major collection.
3. When should a given garbage collection operation be scheduled proactively?

Conclusion

Chrome browser is unique in the way that its lighter and thinner than embedded devices like iPhone or Android, where the whole suite of GC operations runs in one atomic instance of time without interleaving and break down. What we need here is a light-weight, low memory footprint consumption, high throughput, and low latency. V8’s win is in the way it interleaves the GC operation by leveraging the idle time during every 16 ms of threshold time for a frame creation. 

It’s not the mountain top but, the climb that excites me.-CBA