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.
Smalltalk: https://github.com/pavel-krivanek/BarePharo
These RAM prices weren't anticipated so there's been little time for software to adapt. Better monitoring could be a solution but this kind of thing wants to stay hidden.
Running the GC more often wouldn't save much. Dynamic programming languages simply allocate more objects and heavier objects especially with how we use them.
This is far from trivial. Consider the WasmGC proposal, which had a somewhat similar goal.
Then C# came and said "we can't use it, we have different needs". So did Go.
> Then C# came and said
It's worse than that. The WASM GC standards team was warned in advance that the proposal wouldn't work for .NET, and they moved forward with it anyway:
https://github.com/WebAssembly/gc/issues/77
They were also warned about Go (though I'm not sure if they ever actually consulted with golang devs):
https://github.com/WebAssembly/gc/issues/36
More links:
https://github.com/dotnet/runtime/issues/94420
https://github.com/golang/go/issues/63904
No interior pointers, no embedded arrays, and only a subset of Java definitely seems like an odd target. I would have expected at least two different full languages with acceptable porting overhead to be the MVP.
I believe the MVP was chosen specifically to have the same features as JavaScript, so that browser engines can implement it without major changes. So not really an odd target.
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.
> 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.
There’s very minimal state for a weather app. You should be able to sweep the whole thing pretty fast. You could probably statically allocate most of that state.
> There’s very minimal state for a weather app.
Except when it uses some kind of browser engine to render its UI?