As time goes on, I become more and more convinced that OSes need some sort of OS level GC pool which all GCed languages play in rather than having the language runtime provide the GC.

A major part of why these sort of simple applications are taking gbs of memory is because the GC wants to simply grow as much as it can to avoid pauses/jank. There might be 10% of the memory which is actually live in that 1gb. But because it allocates fast enough, the extra headroom is needed.

Even if it isn't the case that the GC is universal, having a shared GC amongst runtimes would be a boon in general. If I have 3 JVMs running, I might give them all 1gb of memory even though really each of them only needs 200mb to get their job done. The extra headroom is for when a burst happens. If I could combine all 3 into 1, I could save a lot of allocation overhead and general memory.

This does sort of exist in java (war deployments), but there are limitations that make it unappealing. For example, each of the JVMs have to be the same version.

Which is what OSes implemented in system languages with automatic memory management usually do, it is an OS service.

Oberon example,

https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kerne...

Active Oberon example,

https://github.com/btreut/a2/blob/master/source/GarbageColle...

Bare metal Java, Go, .NET, Erlang, OCaml,... with bare metal deployments naturally have the runtime take the OS role.

The ram usage in this case is an order of magnitude lower if you install ublock in edge, as other comments have noted. Why would a system level GC affect wasteful adtech?

Any marginal efficiency gains will be wiped out with more adslop. Nathan's law.