Re:Understanding GC in JSC from Scratch
by nilslindemann on Sunday July 31, 2022 @07:01AM
(#32294755)
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".
Re:Understanding GC in JSC from Scratch
by MaxBarraclough on Sunday July 31, 2022 @05:04AM
(#32294345)
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)?
Re:Understanding GC in JSC from Scratch
by sillycross on Sunday July 31, 2022 @06:57AM
(#32294739)
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.
> WebKit’s JavaScript implementation, called JSC (JavaScriptCore), implements all of ES6.
-- https://webkit.org/blog/7536/jsc-loves-es6/
"Avoid fancy words" - Chapter 5, §14, Strunk & White: "The Elements of Style".
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)?
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.