On Mon Mar 9 14:35:22 2026 +0000, Brendan Shanks wrote:
I tried this out (macOS 26.3.1 on Apple Silicon/Rosetta) with a simple EXE that just called GetProcessMemoryInfo, and it reported "Failed to get swapped pages.". What might cause that? I also added a counter to see how many iterations the while loop was doing, at least in that failing case it's doing 680. I worry that applications might call `GetProcessMemoryInfo` or `GlobalMemoryStatusEx` a lot (maybe constantly?), and the overhead of that loop plus the `mach_vm_region_recurse` calls could really add up. Especially in a real app or game which would likely have more regions. Also, should we fill in `PeakVirtualSize` and `PeakPagefileUsage` (maybe just from the non-peak values if there's no other way to get them)? Hi Brendan,
I tried this out (macOS 26.3.1 on Apple Silicon/Rosetta) with a simple EXE that just called GetProcessMemoryInfo, and it reported "Failed to get swapped pages.". What might cause that?
Thanks for catching! This is because the program only requires very little memory, and the system does not need to compress or swap some of its memory, so swapped pages are expected to be zero. But I put the ERR() in the wrong place in v2. In v2, I have tried to handle potential failures from both host_page_size() and mach_vm_region_recurse() in a single ERR(). The v3 should fix this. Actually, on modern macOS, looks like that it is harder to trigger the system to start using swap for an active process; based on my test results, I ran a 3A title in the background, then I can observe the system compressed some of the memory of another native program, where the native program asked the system to allocate about 32GB of memory to it, but the number calculated from mach_vm_region_recurse() was the same as task_vm_info.compressed which means no swap was used for the process. My device has 24GB of memory.
I also added a counter to see how many iterations the while loop was doing, at least in that failing case it's doing 680. I worry that applications might call `GetProcessMemoryInfo` or `GlobalMemoryStatusEx` a lot (maybe constantly?), and the overhead of that loop plus the `mach_vm_region_recurse` calls could really add up. Especially in a real app or game which would likely have more regions.
I actually did have a similar concern about it, but I don't see that there is another way to implement this. I don't know how badly it can affect game performance. I have considered using task_vm_info{internal + compressed} only; this should be fine in many cases because of my test result above. And actually, since macOS has a different memory management policy than Windows, we can't make these numbers exactly as what they mean on Windows. And maybe, overestimating memory usage is worse than underestimating it?
Also, should we fill in `PeakVirtualSize` and `PeakPagefileUsage` (maybe just from the non-peak values if there's no other way to get them)?
We can just fill it with PagefileUsage, but since underestimating it is likely less harmful, and we can't implement it precisely, I think just letting it go unless we can find a real case will be better? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9857#note_131602