Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[GC API] Implement malloc/realloc/free tracking #86

Open
peterzhu2118 opened this issue Aug 12, 2024 · 1 comment
Open

[GC API] Implement malloc/realloc/free tracking #86

peterzhu2118 opened this issue Aug 12, 2024 · 1 comment

Comments

@peterzhu2118
Copy link
Collaborator

The GC API uses system malloc/realloc/free without any MMTk specific accounting.

The existing implementation does this in rb_mmtk_xmalloc_increase_body:

ruby/gc/default.c

Line 8916 in 8082532

rb_mmtk_xmalloc_increase_body(new_size, old_size);

@wks
Copy link

wks commented Aug 19, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants