Conversation

Halvar Flake
@halvarflake
People ask me where my aversion to GC'ed languages in production comes from. One data point: Spoke with a company with a very large cloud footprint recently. Quote: "We spend ~30% of our CPU time in GC, so the way we reduce CPU time is usually by profiling heap allocations." :-)
14
165
Halvar Flake
@halvarflake
In a world where your memory hierarchy has many layers with vastly different latencies, the idea of periodically traversing a graph of *all of memory* does not seem like the right design any more.
6
48
Halvar Flake
@halvarflake
I do wonder what a design for a programming language and garbage collecter would be like that is more cache- and prediction-friendly. Separating out pointer data from other data on the heap sounds like a good step (e.g. don't store pointers in the same object, have a "shadow"...
7
15
Daniel Micay
@DanielMicay
Replying to
@DanielMicay
and
@halvarflake
So, for example, Rc<T> in Rust is non-Send in order to use non-atomic reference counting. Arc<T> is the opt-in to atomic reference counting. A language with abstracted memory management could have the same feature in the type system with non-Send by default for reference types.
1
Daniel Micay
@DanielMicay
Replying to
@DanielMicay
and
@halvarflake
If they use automatic reference counting, it would be almost entirely non-atomic similar to in Rust. If they use tracing GC, they can use task-local heaps for nearly all data. Could also skip scanning most task stacks by having a flag for whether they may have Send references.
1
Show replies