darwin: fix memory meter showing ~64 TB on ARM64 due to unsigned underflow

[EsDmitrii]

Problem

On macOS with Apple Silicon, the memory meter can display wildly incorrect
values — typically ~64 TB used out of 48 GB total. This makes the memory
bar completely unusable.

The root cause is an unsigned integer underflow in Platform_setMemoryValues()
(darwin/Platform.c). The active page count is computed as:

active_count - purgeable_count - external_page_count

All three variables are natural_t (unsigned 32-bit). On systems where
file-backed pages (external_page_count) exceed active_count - purgeable_count,
the subtraction wraps around to ~4,294,867,000 pages. Multiplied by
page_K (16 for ARM64's 16 KB pages), this produces ~64 TB.

Example from a live system (M4 Max, 48 GB RAM):

active_count         = 1,111,998
purgeable_count      =    66,505
external_page_count  = 1,144,396
result (signed)      =   -98,903
result (unsigned)    = 4,294,868,393
× 16 KB              ≈ 64.0 TB         ← displayed by htop

This is a normal state on macOS — the file cache often exceeds
active pages, especially after boot or heavy file I/O.

Fix

Cast each page count to double before subtraction so the arithmetic
is signed, and clamp the result to zero using the existing MAXIMUM()
macro. This avoids the wraparound while preserving the original
calculation semantics.

Both the showCachedMemory=true and showCachedMemory=false code paths
are fixed.

Before / After

Test

Built and ran on macOS Sequoia 15.x, Apple M4 Max (48 GB).
Memory meter now shows correct values consistent with top and vm_stat.

[anitoanto]

Possible fix for #1953

[Explorer09]

htop has a macro called saturatingSub() (in Macros.h). Maybe it's better to use that instead of cast to double.

[Explorer09]

By the way, how did you capture the numbers as reported here?

active_count         = 1,111,998
purgeable_count      =    66,505
external_page_count  = 1,144,396

I hope these numbers are not made up.

[EsDmitrii]

htop has a macro called saturatingSub() (in Macros.h). Maybe it's better to use that instead of cast to double.

Let me double check

[EsDmitrii]

@Explorer09 Good call, updated. Using saturatingSub() with promotion to unsigned long long before the intermediate addition to stay safe across the full range.

About numbers these are live values captured from vm_stat on the affected system (M4 Max, 48 GB, macOS Sequoia). The command:

vm_stat | awk '/Pages active/{print "active_count =", $NF+0} /Pages purgeable/{print "purgeable_count =", $NF+0} /File-backed pages/{print "external_page_count =", $NF+0}'

The key condition is external_page_count > active_count - purgeable_count, which is a normal state on macOS when the file cache is large (e.g. right after boot or heavy file I/O).
Anyone with an ARM64 Mac can reproduce by checking vm_stat — if file-backed pages exceed active pages, htop will show ~64 TB in the memory meter.

[Explorer09]

@EsDmitrii

Anyone with an ARM64 Mac can reproduce by checking vm_stat

I have an M2 MacBook, but unfortunately my use cases with a Mac didn't involve in a large number of file-backed pages. In other words I cannot reproduce the issue during my normal use.

[BenBE]

Please squash/fixup the commits into one as per our style guide …