low-latency GC

[oddp]

On 06.12.20 06:16, Bruce Carneal via Digitalmars-d-learn wrote:
> How difficult would it be to add a, selectable, low-latency GC to dlang?
> 
> Is it closer to "we cant get there from here" or "no big deal if you already have the low-latency GC 
> in hand"?
> 
> I've heard Walter mention performance issues (write barriers IIRC).  I'm also interested in the 
> GC-flavor performance trade offs but here I'm just asking about feasibility.
> 
What our closest competition, Nim, is up to with their mark-and-sweep replacement ORC [1]:

ORC is the existing ARC algorithm (first shipped in version 1.2) plus a cycle collector

[...]

ARC is Nim’s pure reference-counting GC, however, many reference count operations are optimized 
away: Thanks to move semantics, the construction of a data structure does not involve RC operations. 
And thanks to “cursor inference”, another innovation of Nim’s ARC implementation, common data 
structure traversals do not involve RC operations either!

[...]

Benchmark:

Metric/algorithm         ORC    Mark&Sweep
Latency (Avg)      320.49 us      65.31 ms
Latency (Max)        6.24 ms     204.79 ms
Requests/sec        30963.96        282.69
Transfer/sec         1.48 MB      13.80 KB
Max memory           137 MiB       153 MiB

That’s right, ORC is over 100 times faster than the M&S GC. The reason is that ORC only touches 
memory that the mutator touches, too.

[...]

- uses 2x less memory than classical GCs
- can be orders of magnitudes faster in throughput
- offers sub-millisecond latencies
- suited for (hard) realtime systems
- no “stop the world” phase
- oblivious to the size of the heap or the used stack space.

There's also some discussion on /r/programming [2] and hackernews [3], but it hasn't taken off yet.

[1] https://nim-lang.org/blog/2020/12/08/introducing-orc.html
[2] https://old.reddit.com/r/programming/comments/k95cc5/introducing_orc_nim_nextgen_memory_management/
[3] https://news.ycombinator.com/item?id=25345770