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

Expose APIs for bindings to check if (metadata) memory has been mapped or not #1152

Open
k-sareen opened this issue Jun 23, 2024 · 2 comments

Comments

@k-sareen
Copy link
Collaborator

k-sareen commented Jun 23, 2024

This is used in the cases where the binding needs to iterate on a metadata (for example the VO-bit). The is_mapped_address API exists but I was specifically thinking of exposing the SFT get_checked function as it's likely useful for bindings to be able to query the SFT in such cases.

@qinsoon
Copy link
Member

qinsoon commented Jun 24, 2024

I think we want to provide methods to iterate metadata, rather than letting the users to do that at the binding side.

To clarify some of the stuff in the issue:

is_mapped_address checks with the mmapper. Our data memory and side metadata memory are both mmapped and tracked by the mmapper. So is_mapped_address can tell if metadata memory is mapped. However, the binding needs to calculate the side metadata address from the data address. I believe the calculation methods are not public, and I don't think we should make it public.

SFT checks with a SFT map. Unmapped memory also has its SFT entry in the map. Also SFT is not public either. It is an internal mechanism for MMTk, and we should not expose it to the binding. We expose public APIs such as checking if an object is alive.

@k-sareen
Copy link
Collaborator Author

Yes I agree. I mentioned on Zulip that a generic iteration API for side metadata which allows going forward or backward would be ideal. Interior pointers are not the only reason to iterate through a bit map. Many algorithms require such a feature.

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