Understanding GC in JSC from Scratch

webkit.org

91 points·feross··6 comments

Oddly enough, JSC is never defined in the article. From elsewhere:

> WebKit’s JavaScript implementation, called JSC (JavaScriptCore), implements all of ES6.

-- https://webkit.org/blog/7536/jsc-loves-es6/

That’s because it’s so awesome that it needs no definition.

That was the first thing I noticed too. Using it in the heading already hurts the eyes. Not getting it defined in the text is cruel. Why not just write it out: "JavaScriptCore"?

"Avoid fancy words" - Chapter 5, §14, Strunk & White: "The Elements of Style".

Great write-up!

Something I'm not getting, perhaps I'm missing something terribly obvious:

> during a full GC, we should also accept l_markVersion that is off-by-one. In that case, we know the isMarked bit accurately reflects whether or not a cell is live, since that is the result of the last GC cycle.

Here's part of the related footnote:

> any number of eden GC cycles may have run between the last full GC cycle and the current full GC cycle, but eden GC does not bump mark version. So for any object born before the last GC cycle (no matter eden or full), the isMarked bit honestly reflects if it is live

Couldn't an object have become non-live since the last GC cycle (whether eden or full)?

Yes, the object can become unreachable, but we won't know it until the end of the current GC cycle (and the whole purpose of GC is to figure that information out). So yes, even if it has become unreachable, it is live (and must be live) until the end of the cycle.

I think the point you missed is: the function 'cellContainsLiveObject' is not used by GC, it is used by allocator to tell if the cell is available for allocation. So it's fine if the function returns true but the object is actually unreachable, but not the other way around.

That’s right.

Reply on news.ycombinator.com