Comment by cogman10

17 hours ago

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.

11 comments

cogman10

Reply
afdbcreid  14 hours ago

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.

dominicrose  2 hours ago

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.

mwkaufma  17 hours ago

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.

burnt-resistor  29 minutes ago

That's what the OS VMM subsystem provides... abstraction and management of the memory hierarchy to decide what RAM to use and what RAM regions gets discarded or swapped to/from disk.

If an OS were built entirely around a single instance of HiPE/BEAM similar to LING, it might be possible. For efficiency of apps, ditch GC where possible and use precise memory allocation. When that's not possible, use thread-local, immutable storage pools of objects like BEAM so GC can be concurrent and parallel. The messiest way is to do it like the JVM and other systems that throw all objects into a single pool and require pausing the world and expensive graph walks to clean up.

goalieca  14 hours ago

> 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.

  • Hackbraten  14 hours ago

    > There’s very minimal state for a weather app.

    Except when it uses some kind of browser engine to render its UI?