"I don't understand how virtual memory systems work, but I know that if I write an article complaining about <new Apple thing> I'll get a ton of traffic".
The Activity Monitor screenshot in the embedded tweet even explains what's going on. The system has 64G of physical memory. A bit less than 50GB is in use (so 14G is completely idle, wasted). 7G are wired (kernel, device buffers, etc.) and can't be paged. 38G are in used caching things for applications, and about 180G worth of compressed data (mostly zeros I'd say, since it's only using 5G of real memory) has avoided being paged out.
There is literally no memory pressure in this system, and no evidence of leakage in those numbers. Darwin deliberately tries to keep as much DRAM as possible live to minimise page-in and decompression costs; it literally can't find anything worth paging in or decompressing to fill those last 14G. That's a vacuum, not pressure.
I'm not going to debate the stability issues that the article author is complaining about; I do hope they have all of the crash reporting features enabled so that their crash data can be used by the various developers to help fix things.
But I would hope that before writing yet another stupid clickbait article, they pick a topic they know something about.
No, first of all, there is a screenshot in the article showing high memory pressure. That needs to be taken into account by your analysis of the author's intentions and understanding.
Second, I have one of the new new systems with a lot of RAM and when WindowServer takes up 20-30GB of RAM, and other apps take up 2-10GB more than they should, I see high memory pressure. There are other reports of this. Don't extrapolate too much from one screenshot showing a system shortly after reboot.
It's possible that most of the bloat from this bug gets pushed to swap and harmlessly stays there until reboot, to leave space in DRAM for actually useful application memory, but the typical user doesn't have guarantees of this based on the instrumentation available to them.
The 38G isn't "cached app memory" (there is no such thing), it's actual resident memory, calculated as the sum of the second column. The same as "RES" in Linux. There is no memory cache that differentiates apps from non-apps (whatever that is?), there is just regular file memory cache, which is labelled below the application memory section, shown to be using 13G.
Every file you open on your system (read: app you open, file that macOS accesses, etc.) will be automatically read into the file cache and left there until some event, such as not having any unused memory since all of it is used as cache, requires some contents of the cache to be evicted to make room for an application.
If this system had been low on RAM, this "Control Center" app would have been paging to disk to make room for the gigantic 26G it "needs" (the fact that it needs this much is a bug/leak. It should not be showing a number that high in that field, which is the resident memory required by the app.)
In summary, unused memory is meant to be used for caching files (see https://www.linuxatemyram.com/). The cache is lowest priority and almost considered "free" memory, in the sense that the cache can be evicted anytime to make room for actual application resident memory. In this case, "Control Center" is using 26G of resident memory, not cache (which is not shown in that column at all.) This is a bug/memory leak.
The second screenshot literally shows safari occupying 30+ G of memory. What the hell is it caching? The entire internet?
Or maybe is it just memory leak?
The Activity Monitor screenshot in the embedded tweet even explains what's going on. The system has 64G of physical memory. A bit less than 50GB is in use (so 14G is completely idle, wasted). 7G are wired (kernel, device buffers, etc.) and can't be paged. 38G are in used caching things for applications, and about 180G worth of compressed data (mostly zeros I'd say, since it's only using 5G of real memory) has avoided being paged out.
There is literally no memory pressure in this system, and no evidence of leakage in those numbers. Darwin deliberately tries to keep as much DRAM as possible live to minimise page-in and decompression costs; it literally can't find anything worth paging in or decompressing to fill those last 14G. That's a vacuum, not pressure.
I'm not going to debate the stability issues that the article author is complaining about; I do hope they have all of the crash reporting features enabled so that their crash data can be used by the various developers to help fix things.
But I would hope that before writing yet another stupid clickbait article, they pick a topic they know something about.