Kurt Stephens

Joe Damato drills deep into the implied contracts of the MRI/C API:

http://timetobleed.com/the-broken-promises-of-mrireeyarv/

The need for RB_GC_GUARD(v) is probably due to faulty register spilling in the MRI eval/thread/GC machinery; the PRE_GETCONTEXT() and POST_GETCONTEXT() macros in MRI eval.c might be the real problem.

In contrast, the Boehm-Demers-Weiser (BDW) GC library manages to scan registers without demanding client code to explicitly flush pointers to the stack.

However, in general, it is problematic, in language design practice to make GC contracts completely transparent to API client code. This difficultly is explicitly solved in the design of Lua:

Passing a Language through the Eye of a Needle — How the embeddability of Lua impacted its design: http://queue.acm.org/detail.cfm?id=1983083

Lua mediates all object references through stack manipulations. They were able to implement a generational write-barrier with little (or no) GC API contracts.

MRI does not need a read or write barrier; it’s unclear why RB_GC_GUARD() is needed at all except to cover up a bug elsewhere.