2 ms·

I suspect that GC'd languages could mitigate this problem by introducing regions; separate areas of memory that cannot point at each other. Pony actors [0] have

I suspect that GC'd languages could mitigate this problem by introducing regions; separate areas of memory that cannot point at each other. Pony actors [0] have them, and Cone [1] and Vale [2] are trying new things with them. If golang had this, then it might not ever need to run its GC because it could just fire up a new region for every request. The request will likely end and blast away its memory before it needs to collect, or it could choose to collect only when that particular goroutine/region is blocked. Extra benefit: if there's an error in one region, we can blast it away and the rest of the program continues! [0] https://tutorial.ponylang.io/types/actors.html#concurrent https://tutorial.ponylang.io/types/actors.html#concurrent [1] https://cone.jondgoodwin.com/fast.html https://cone.jondgoodwin.com/fast.html [2] https://verdagon.dev/blog/seamless-fearless-structured-concurrency https://verdagon.dev/blog/seamless-fearless-structured-concu...

jatone 5y ago
or you know; just pace the GC mark and sweep algorithm. which is what go is doing now.
- verdagon 5y ago
  Correct me if I'm wrong, but IIRC pacing would still cause a latency spike, it would just be a more strategically-timed latency spike.
  - jatone 5y ago
    sure - https://github.com/golang/go/issues/44167 https://github.com/golang/go/issues/44167. you'll see the new design the CPU util only increases in GC CPU utilizations when you're actually allocating heavily. which makes sense you're doing more work. this should completely resolve the problem discord had; since their system was in a steady state.
- abeltensor 5y ago
  You are always going to have some kind of latency spike with a sweeping GC; even if that spike is tiny.
  - jatone 5y ago
    not really. if you're in a steady state (like discord was) you wouldn't see any spikes. you'd have a consistent utilization. if you start allocating heavily then you would potentially see an increase. which makes sense, you're increasing your workload, utilization needs to increase. but still not necessarily a 'spike'

jatone 5y ago

or you know; just pace the GC mark and sweep algorithm. which is what go is doing now.

verdagon 5y ago
Correct me if I'm wrong, but IIRC pacing would still cause a latency spike, it would just be a more strategically-timed latency spike.
- jatone 5y ago
  sure - https://github.com/golang/go/issues/44167 https://github.com/golang/go/issues/44167. you'll see the new design the CPU util only increases in GC CPU utilizations when you're actually allocating heavily. which makes sense you're doing more work. this should completely resolve the problem discord had; since their system was in a steady state.
abeltensor 5y ago
You are always going to have some kind of latency spike with a sweeping GC; even if that spike is tiny.
- jatone 5y ago
  not really. if you're in a steady state (like discord was) you wouldn't see any spikes. you'd have a consistent utilization. if you start allocating heavily then you would potentially see an increase. which makes sense, you're increasing your workload, utilization needs to increase. but still not necessarily a 'spike'