You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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 SFTget_checked
function as it's likely useful for bindings to be able to query the SFT in such cases.The text was updated successfully, but these errors were encountered: