4 ms·

Manual memory management means your memory management is tightly interleaved with application code, with both competing for the same limited cache space. A trac

Manual memory management means your memory management is tightly interleaved with application code, with both competing for the same limited cache space. A tracing GC batches memory management, using cache better and not as frequently evicting your application’s data out of cache. A GC can also let you use more efficient concurrent data structures - many sophisticated concurrent objects require a tracing GC for implementing correctly - which can improve the performance of your application code.

tialaramex 4y ago
> many sophisticated concurrent objects require a tracing GC for implementing correctly What sort of "sophisticated concurrent objects" are you thinking of?
- chrisseaton 4y ago
  Implementing many lock-free data structures without a GC is still a research topic, for example requiring conversion to use epoch allocation.
  - tialaramex 4y ago
    This still seems very vague, I was looking for concrete examples where quite different arrangements like hazard pointers are for some reason impossible.
    - chrisseaton 4y ago
      Hazard pointers, epoch reclamation yeah are both examples of tools to work around the lack of GC, but they require new work to figure out how to apply them and they harm your throughput which is probably why you wanted these data structures in the first place. https://medium.com/@tylerneely/fear-and-loathing-in-lock-free-programming-7158b1cdd50c https://medium.com/@tylerneely/fear-and-loathing-in-lock-fre...
- yencabulator 4y ago
  Even just read-copy-update without refcounts is very hard without GC. Linux kernel can do RCU without refcounts largely because it's in complete control of CPU cores and scheduling; userspace can't pull of the same tricks. Meanwhile, with GC, it's just https://pkg.go.dev/sync/atomic#Value https://pkg.go.dev/sync/atomic#Value https://www.kernel.org/doc/html/latest/RCU/whatisRCU.html https://www.kernel.org/doc/html/latest/RCU/whatisRCU.html
  - tialaramex 4y ago
    > Even just read-copy-update without refcounts is very hard without GC To me "it could be more difficult without" and "requires" are quite different claims, especially in the context of what's possible and why.
- ruuda 4y ago
  Here's one design that's nice to do for servers in GC'd functional languages, and hard to achieve without GC. Have the state of your application be a persistent data structure (one that you can efficiently update such that both the old and new version remain available, as opposed to in-place mutation). Then hold a "current state" pointer, that gets updated atomically. Endpoints that only read the state can read the pointer and then complete the request with a consistent view of the state, while writes can be serialized, build the new state in the background, and when it's done, swap the pointer to "publish" the new state. This way reads get a consistent view without blocking writes, and writes do not block reads. (Unlike an implementation where you mutate the state in-place, and you would need to protect it with a mutex.) It is possible to do this in non-gc'd languages too, but then persistent data structures are unwieldy, and cloning the full state for every update may be prohibitively expensive.
  - Lvl999Noob 4y ago
    Do you mean this? https://github.com/jonhoo/left-right https://github.com/jonhoo/left-right I am not sure of the performance or implementation difficulty but the data structure seems to be what you are talking about.
    - ruuda 4y ago
      Not exactly, but it looks similar. With what I was talking about you can have as many versions around as you need. An example would be using (TVar (HashMap k v)) in Haskell.

tialaramex 4y ago

> many sophisticated concurrent objects require a tracing GC for implementing correctly What sort of "sophisticated concurrent objects" are you thinking of?

chrisseaton 4y ago
Implementing many lock-free data structures without a GC is still a research topic, for example requiring conversion to use epoch allocation.
- tialaramex 4y ago
  This still seems very vague, I was looking for concrete examples where quite different arrangements like hazard pointers are for some reason impossible.
  - chrisseaton 4y ago
    Hazard pointers, epoch reclamation yeah are both examples of tools to work around the lack of GC, but they require new work to figure out how to apply them and they harm your throughput which is probably why you wanted these data structures in the first place. https://medium.com/@tylerneely/fear-and-loathing-in-lock-free-programming-7158b1cdd50c https://medium.com/@tylerneely/fear-and-loathing-in-lock-fre...
yencabulator 4y ago
Even just read-copy-update without refcounts is very hard without GC. Linux kernel can do RCU without refcounts largely because it's in complete control of CPU cores and scheduling; userspace can't pull of the same tricks. Meanwhile, with GC, it's just https://pkg.go.dev/sync/atomic#Value https://pkg.go.dev/sync/atomic#Value https://www.kernel.org/doc/html/latest/RCU/whatisRCU.html https://www.kernel.org/doc/html/latest/RCU/whatisRCU.html
- tialaramex 4y ago
  > Even just read-copy-update without refcounts is very hard without GC To me "it could be more difficult without" and "requires" are quite different claims, especially in the context of what's possible and why.
ruuda 4y ago
Here's one design that's nice to do for servers in GC'd functional languages, and hard to achieve without GC. Have the state of your application be a persistent data structure (one that you can efficiently update such that both the old and new version remain available, as opposed to in-place mutation). Then hold a "current state" pointer, that gets updated atomically. Endpoints that only read the state can read the pointer and then complete the request with a consistent view of the state, while writes can be serialized, build the new state in the background, and when it's done, swap the pointer to "publish" the new state. This way reads get a consistent view without blocking writes, and writes do not block reads. (Unlike an implementation where you mutate the state in-place, and you would need to protect it with a mutex.) It is possible to do this in non-gc'd languages too, but then persistent data structures are unwieldy, and cloning the full state for every update may be prohibitively expensive.
- Lvl999Noob 4y ago
  Do you mean this? https://github.com/jonhoo/left-right https://github.com/jonhoo/left-right I am not sure of the performance or implementation difficulty but the data structure seems to be what you are talking about.
  - ruuda 4y ago
    Not exactly, but it looks similar. With what I was talking about you can have as many versions around as you need. An example would be using (TVar (HashMap k v)) in Haskell.