m1 base ... 7 core vs 8 , 8vs 16gb .... mostly adobe stuff and web browsing.

[armoured]

Yeah, things doesn't add up. I know nothing about memory allocation on macOS and how Chrome specific handle it.

Yep, memory management is not a simple topic. The easiest/best way to test would have been to quit chrome and see if that resolved the issue.

The point about istat menus 'aggregating' the memory of sub-processes (which I didn't know) really does suggest it wasn't an istat error but something in chrome (and the size sounds more like a memory leak than a thousand pages open - I hope anyway).

One other tidbit about your swapping: first, 6 gig swap file is pretty big. But even more important than swap file is whether it's actively swapping (that would usually be the slowdown). Even on an older 11" airbook I rarely get a swapfile above 2gb, and that's when doing stuff the 4gb (!) ram system really should not be doing.

Another possible explanation why swap file was less big than the 50gb istat number might imply - shared resources. The system and I would presume chrome doesn't have to duplicate code etc that's already in memory elsewhere.

 

[leman]

That's all really interesting - thanks for the insights @Coheebuzz, @armoured, @Krevnik. I know that Chrome can be a memory hog, and this would suggest that there was a memory leak somewhere. What I'm not clear on though, is that out of that 50gb, given that obviously there is not that much RAM, the rest would be presumably in swap? The swap space readout from iStat is showing 6.62GB, so what explains this discrepancy do you think?

I don’t think there is much mystery here. Apple relies on copy-on-write behavior for managing RAM. Chrome uses a separate process for each of its tabs, and each tab process is a clone of another tab process. Every tab has its own memory space (they are separate processes after all), but a lot of actual physical RAM is shared between all of them - code, common data etc. It’s fairly easy to make an app that will occupy terabytes of memory space while in reality only using few MB of real RAM.

 

[armoured]

I don’t think there is much mystery here. Apple relies on copy-on-write behavior for managing RAM. Chrome uses a separate process for each of its tabs, and each tab process is a clone of another tab process. Every tab has its own memory space (they are separate processes after all), but a lot of actual physical RAM is shared between all of them - code, common data etc. It’s fairly easy to make an app that will occupy terabytes of memory space while in reality only using few MB of real RAM.

It's like you said what I meant to say but you know what you're talking about and use the proper terminology! Makes more sense when you do it...

 

[Krevnik]

I don’t think there is much mystery here. Apple relies on copy-on-write behavior for managing RAM. Chrome uses a separate process for each of its tabs, and each tab process is a clone of another tab process. Every tab has its own memory space (they are separate processes after all), but a lot of actual physical RAM is shared between all of them - code, common data etc. It’s fairly easy to make an app that will occupy terabytes of memory space while in reality only using few MB of real RAM.

I think my counter-argument here is that browser memory is dominated by resources that shouldn't be shared though: the website state/resources themselves. Since isolating each tab in its own process is about security, there's limits to what copy-on-write can really do here. The bulk of the shared memory space should be read-only memory pages (fork or no), and the benefits of copy-on-write can evaporate quickly when talking about resource demands from the website being displayed depending on how big it is.

Looking at the split in something like Activity Monitor (but using Safari) with my two biggest tabs show that shared memory is a fraction of the private memory. There are cases where shared memory can exceed private memory, but it very much depends on the website and what it is doing.