Open wks opened 1 year ago
We isolated most MMTk-related functions into mmtk_support.c
and mmtk_support.h
. There are still changes guarded by #if USE_MMTK
in gc.c
. Those things are mainly related to object allocation, object scanning, write barrier, and weak table / finalization / obj_free
handling. Some of the weak tables are fields of the private struct objspace
, such as id_to_obj_tbl
and obj_to_id_tbl
. We also expose some private functions in gc.c
that needs to be called by mmtk, such as gc_mark_root
for root scanning, gc_mark_children
for scanning objects and functions for executing obj_free
.
We should further separate functions that are specific to MMTK and functions that modifies the Ruby VM's behaviours in areas closely related to GC. The latter includes weak reference and finalization. That will also help Ruby isolate GC into a separate module and allow CRuby to switch between different GC implementations. See https://bugs.ruby-lang.org/issues/20470
Currently, the code base, especially
gc.c
, is littered with ad-hoc#ifdef MMTK
blocks. While it works, it is better if we can isolate MMTk-related functions and data structures into a dedicated source file, such asmmtk.c
.There are some difficulties doing so.
gc.c
. They are related to object layouts, marking, sweeping and so on.gc.c
has been the only source file related to GC in the Ruby code base. This may explain why there has never been a need to expose any GC implementation details to other files.gc.c
is large, too, having about 16000 lines of code. Although it is much better than the 35000+ lines of code ingc.cpp
in .NET core (See https://github.com/dotnet/runtime/issues/4024 and the avatar of https://github.com/Maoni0), it is still very hard to maintain.Isolating MMTk-related code is one small step towards making a well-defined VM-GC interface for Ruby, because the places that need to be changed indicates the difference between GC implementations as well as places where the GC is too tightly coupled with the VM.