wks
commented
3 weeks ago MMTk provides a callback function Collection::vm_live_bytes() -> usize. The VM binding implements this function to return the amount of memory allocated outside the MMTk heap, but needs to be taken into account for triggering GC. Similarly, I think Ruby's GC API can just provide one function to return the amount of memory allocated by xmalloc, so that other GC implementations can make use of that number, too. Currently we count the delta rather than the absolute amount because some xmalloc invocations are untracked (the so-called mimmalloc). But that's OK. It only needs to be an approximate amount, as long as it is sufficient to trigger GC in time.
Ideally, the size should be whole pages. That means even if a page holds only one small object, the number should count the whole page in because (1) page is the unit the operating system maps memory, and (2) real-world memory allocators usually don't allow other users to allocate into the same page it is holding, which means the rest of the page cannot be reused by other allocators, especially the MMTk GC. But this may not always be possible. For example, if we are using the system's malloc, we won't know the page-level layout of the malloc allocator. We only know it if we choose a specific malloc implementation (such as jemalloc, tcmalloc, mimalloc, etc.). So the total number of bytes allocated by malloc should be a good approximation.
The GC API uses system malloc/realloc/free without any MMTk specific accounting.
The existing implementation does this in
rb_mmtk_xmalloc_increase_body:https://github.com/mmtk/ruby/blob/8082532b9f720a1e7508ac32641dcfbbf51dd518/gc/default.c#L8916