Kurt Stephens

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

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:

Simple patch for C WeakRefs in MRI 1.9.
Should be portable to MRI 1.8.

http://redmine.ruby-lang.org/issues/show/4168

https://github.com/kstephens/ruby/commit/0942a955c649c39d3be4db13dbfb0ba...

Excellent introduction to Ruby MRI’s GC and memory debugging:

http://timetobleed.com/garbage-collection-slides-from-la-ruby-conference...

I’m planning a new release of TM v.04, originally outlined here: http://kurtstephens.com/research/tredmill

New documentation is located at:

http://kurtstephens.com/pub/tredmill/current/doc/html/index.html

Code to follow shortly.

Interesting paper on weak data structures and implementations:

http://www.haible.de/bruno/papers/cs/weak/WeakDatastructures-writeup.htm...

See also:

http://www.memorymanagement.org/

Introduction

TM is a real-time, non-relocating, conservative, allocator using type- and color-segregated lists, based on Henry Baker’s “Treadmill” allocator. The source code for TM is located at http://kurtstephens.com/pub/tredmill.

TM interleaves marking, scanning and sweeping during each mutator’s call to tm_alloc().

TM attempts to limit the amount of work in the collector to avoid stopping the world for long periods of time. It does not require a separate thread for the collector as all collection activities are interleaved with allocation.

Full documentation is located at: http://kurtstephens.com/pub/tredmill/current/doc/html/index.html