How often do your computer exclusively runs Chrome? How easily can the OS take the memory back from Chrome to run something else (that one is easy, it can not, except on the last case scenario where it kills process).

> How easily can the OS take the memory back from Chrome to run something else (that one is easy, it can not, except on the last case scenario where it kills process).

It actually can. It's called swapping. An amazing technology from the 90s.

That's not what GP meant, the analogous situation is loading GBs of data into a database, resulting in a GBs sized file on disk. If you truncate the data, it's gone, but the database won't actually shrink the file on disk unless you vacuum too. Chrome might not be using all the memory it has claimed, but it's not necessarily releasing all that it can back to the system either.

> but it's not necessarily releasing all that it can back to the system either.

That's exactly the point of swapping. Memory which was not used in a (relatively) long time is taken away forcefully from the process if there is memory pressure on the system.

So it doesn't matter if Chrome releases it or not, it will be taken away if it just sits there.

> is taken away forcefully

To disk. Waiting for the memory a badly behaved app overzealously ate up without using to finish flushing to disk before being able to use it is worse than simply having the memory readily available. This is why I always disable swap, opting to let bad processes die, sometimes even pulling the trigger myself.

If you ever hit actual swapping, then your system performance is already way past the point of no return.

In modern systems, paging is okay. But not swapping.

In even more modern systems, with NVMe NAND storage, even swapping is ok.

> from the 90s.

From the 60s. Atlas computer had virtual memory. I originally thought it was the System360.

https://www.computerhistory.org/timeline/1962/

That's what the virtual memory system does, provided you're not running with swap disabled. A page fault isn't hard for the kernel to handle, it's just a severe performance hit.

Does it gracefully & rapidly clean house if another app needs some? Does the extra usage benefit you in any way at all, to make up for the disk cache it gets used as otherwise?

> Is there some benefit to having memory sitting around empty and idle?

Yes, modern operating systems use free RAM as cache for the HDD. If you have an I/O intensive process, having a large amount of RAM is really helpful.

If you have any kind of workload with IO patterns that are not embarassingly parallel you want your files to be in the page caches, i.e. RAM, to minimize the access latencies and thus the walltime of your workload.

For that to work applications shouldn't be gobbling up all the ram, instead they should leave it to the OS to cache data.

Sure, NVMe drives help, but loading things from RAM is snappier still.

Also, those huge memory footprints themselves can also cause issues. E.g. they can increase GC pauses in GCed languages or decrease cache hit rates when allocations are scattered all over the place.

I played minecraft last year again and it did exactly what you said. I was constantly running out of my paltry 8GB of RAM on a linux system that wasn't running anything except minecraft. If I got unlucky it went up from 98.5% RAM utilization to 100% and then the whole system locked up. It probably was the worst gaming experience in my whole life.

So should I write software that just leaks and not worry about it?

That's the Electron way isn't it?

Cut corners and offload the trade-offs onto your end users.