News for hackers. Stuff that matters.

A comment on Ruby Garbage Collection Deep Dive: Tri-Color Mark and Sweep. Parent comment

Re:Ruby Garbage Collection Deep Dive: Tri-Color Mark and Sweep by ufo on Thursday February 18, 2021 @02:18PM (#26184229)
This is very important to remember. A lot of the time, the incremental GC is still single threaded. The difference is that while a two-color "stop the world" algorithm has to collect everything in one long GC pause, the three-color incremental algorithm can spread the work over a series of smaller pauses.
[ Parent | on HN ]
Re:Ruby Garbage Collection Deep Dive: Tri-Color Mark and Sweep by treis on Thursday February 18, 2021 @02:30PM (#26184350)
How does it handle the case where a RVALUE is added to an already processed black node in between pauses?
[ Parent | on HN ]
Re:Ruby Garbage Collection Deep Dive: Tri-Color Mark and Sweep by tenderlove on Thursday February 18, 2021 @02:41PM (#26184473)
MRI implements a write barrier. You can check out the write barrier implementation here:

  https://github.com/ruby/ruby/blob/7bd93293621b85a87e7e117317612bb0a84efb7a/gc.c#L7802
The behavior for writes on a black object is defined in this function:

  https://github.com/ruby/ruby/blob/7bd93293621b85a87e7e117317612bb0a84efb7a/gc.c#L7766
Basically when a black -> white reference is written during incremental marking, the white object will be grey'd and added to the mark stack.

Happy Thursday!

[ Parent | on HN ]
Re:Ruby Garbage Collection Deep Dive: Tri-Color Mark and Sweep by ufo on Thursday February 18, 2021 @02:56PM (#26184622)
Alternatively, you can also move the gc "backwards", changing the black object. In Lua, sometimes the write barrier recolors the white child object to grey and sometimes it recolors the black parent object to grey.

IIRC, the motivation for going backwards is that if you assign a large number of white children, recoloring the parent once is faster than recoloring all the children.

[ Parent | on HN ]