Doesn't really depend on what is the granularity here? In other words this bug title is missing the "where" part.
My guess is that here we are talking about ProcessMemoryDump::CountResidentBytes .

I don't know enough of OSX, but here's my doubt:
I fully buy that if we query a full region (as in, the result of a prior mmap operation) mincore and mach_vm_region will return the same result (maybe partially out of date % some caching effect of the OS counter, but I don't really care).
Instead my question is, what happens if you want to analyze an inner range of a mmap-ed region?
say:
void* x = mmap(4MB, ...)
mincore(x, 2MB, ...)

What will mach_vm_region return? is it even possible to pass arbitrary page-aligned addresses to it?

Concretely speaking I think that CountResidentBytes is used only by the chrome discardable MDP. I don't know if there is any guarantee that the discardable segments map 1:1 with vm regions.
Taking a step back, are we seeing the discardable MDP taking long times? Or are we planning to use that on new MDPs and it takes time?

If we know that discardable regions only call CountResidentBytes with whole virtual regions then I am happy with replacing the CountResidentBytes to use mach_vm_region, with a comment saying it only works for whole regions on Mac.

If there is a chance that discardable could use segments of the allocated regions then we could just add a new function to VmRegionResidentBytes() to wrap mach_vm_region.

I think the intention here is to be able to count the resident size of shared memory regions in a faster way. I am not sure if we have a similar api on Linux/Android that we could use.

Archiving P3s older than 1 year with no owner or component.