One crucial part of making CRuby perform well with MMTk is making String, Array and MatchData not rely on obj_free to free its underlying buffers allocated by xmalloc. We introduced imemo:mmtk_strbuf and imemo:mmtk_objbuf as alternatives that are allocated in the GC heap. In theory, those changes only needs the GC to be able to allocate objects of any sizes, and the GC doesn't have to be MMTk.
It will be helpful to guard those code using special macros (and run-time checking variable, too, if we want them to be enabled/disabled at run time) instead of guarding them using #if USE_MMTK and/or rb_mmtk_enabled_p(). This will also make it possible to push those changes to the upstream once CRuby introduces arbitrary-size allocation.
One crucial part of making CRuby perform well with MMTk is making String, Array and MatchData not rely on
obj_freeto free its underlying buffers allocated byxmalloc. We introducedimemo:mmtk_strbufandimemo:mmtk_objbufas alternatives that are allocated in the GC heap. In theory, those changes only needs the GC to be able to allocate objects of any sizes, and the GC doesn't have to be MMTk.It will be helpful to guard those code using special macros (and run-time checking variable, too, if we want them to be enabled/disabled at run time) instead of guarding them using
#if USE_MMTKand/orrb_mmtk_enabled_p(). This will also make it possible to push those changes to the upstream once CRuby introduces arbitrary-size allocation.