You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 byxmalloc
. We introducedimemo:mmtk_strbuf
andimemo: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/orrb_mmtk_enabled_p()
. This will also make it possible to push those changes to the upstream once CRuby introduces arbitrary-size allocation.The text was updated successfully, but these errors were encountered: