mmtk
Support for uncooperative languages with liballocs
One of MMTk's goals is that it will support conservative GC.
The least ambitious end of this objective is supporting memory-safe languages designed for GC that don't have precise stack maps. We know that we can do this efficiently.
The more ambitious goal is to support 'uncooperative' languages such as C and C++, along the lines of BDW.
An interesting avenue for achieving the more ambitious goal would be to work with liballocs, which is developed by Stephen Kell. It is well worth while taking a read of the liballocs README, to get a sense of what liballocs is, how it works, and why it might be useful for this project.
I was discussing this with @fabianmuehlboeck , who currently uses BDW for nom https://github.com/fabianmuehlboeck/monnom/blob/main/sourcecode/Runtime/gcinclude_config.h https://github.com/fabianmuehlboeck/monnom/blob/main/sourcecode/Runtime/boehmgcinterface.cpp
Providing a dropin replacement for BDW could be very useful for people adopting MMTk in an existing language implementation, before a more full-featured port by writing a proper MMTk binding.
I wonder whether we should have a separate issue tracking a BDW-like library based on MMTk.
Providing a dropin replacement for BDW could be very useful for people adopting MMTk in an existing language implementation, before a more full-featured port by writing a proper MMTk binding.
I wonder whether we should have a separate issue tracking a BDW-like library based on MMTk.
What about making a "super VM binding" which appears to mmtk-core as a VM binding, but appears to concrete applications as a library compatible to BDW? It just forwards malloc to mmtk::memory_manager::alloc, and implement the Collection, Scanning and other traits with POSIX threads and conservative scanning. Then we can push this thing out of mmtk-core.
I was actually working on something like this already and had prototype working. It was precise on heap + conservative on stack API based around MMTk but I suppose with enough work I can make it configurable (e.g fully precise, semi-precise, fully conservative modes).
If there's any interest I can create a repo for this
iirc BDW has to do a bit of a dance to get the application threads to pause for a STW collection. We would have to do engineer this carefully for uncooperative languages.
iirc BDW has to do a bit of a dance to get the application threads to pause for a STW collection. We would have to do engineer this carefully for uncooperative languages.
I was just having AtomicBool on in_mmtk_api inside each Thread before sending signal to a thread, if its true then we spin and wait for thread to exit MMTk API. So we do not end up locking MMTk entirely