5 ms·

Each release of Go seems to have yet another garbage collection algorithm, targetting a different use case each time. Presumably the previous use cases are left

Each release of Go seems to have yet another garbage collection algorithm, targetting a different use case each time. Presumably the previous use cases are left behind, ready for a future update going back to target them too. This leads to an infinite loop of GC alterations. Does anyone feel confident that a 'good enough for everyone' GC will ever be produced? If not, surely the language designers should settle on picking a type of program that they will optimise for, and sticking to it.

oleganza 10y ago
GC highlight time-memory tradeoff at its worst because GC-based languages typically do not allow programmer to explicitly express his memory model forcing a lot of unnecessary "garbage" to be created. In Ruby all objects that do not fit in a tagged pointer are objects. In Go and Java some types are specifically optimized for being stack-based "value" types that reduces amount of work for GC. I personally like the "ARC" approach with ObjC and Swift where compiler statically adds and optimizes reference counting routines, promotes objects to stack when possible and requires programmer to manually resolve cyclic references (and Xcode supports nice methods to debug and visualize memory in order to detect unintentional cycles). Accidental memory cycles are rare enough and quite debuggable at a very little mental cost to mark some references as "weak" or "unowned". But the long-term performance and memory exhaustion issues caused by GCs are completely bypassed.
- pjmlp 10y ago
  The problem with RC as algorithm is that it increases locking on shared data structures, thus cache contention, and you still have "stop the world" when destroying a complex data structure causes a cascade of deletions. There was a Swift talk exactly about struct vs reference types and making use of COW data structures to reduce ARC impact.
ngrilly 10y ago
> Presumably the previous use cases are left behind No, they are not. The optimization discussed here adds something to the existing GC, and removes nothing. > Does anyone feel confident that a 'good enough for everyone' GC will ever be produced? The Go GC is constantly improving, and its performance in Go 1.6 and 1.7 is considered very good my most users.
- vvanders 10y ago
  There's a subthread further down that points to this exact type of regression: https://news.ycombinator.com/item?id=11970313 https://news.ycombinator.com/item?id=11970313 Without full memory control you're always going to making trade-offs in terms of performance. Hopefully the GC is "good enough" for your use case but there will never be a one-size fits all GC.
  - enneff 10y ago
    FWIW that "regression" looks like a program that depends on particular runtime characteristics to generate "artistic" output. Not really the kind of issue you can realistically develop around. In almost all practical programs the new GC (in 1.5) was a significant win, or at worst no change.
- madgar 10y ago
  > The Go GC is constantly improving, and its performance in Go 1.6 and 1.7 is considered very good my most users. Also true of Ruby or PHP. Which perform abysmally. "Most users" needs aren't what we look for to define technical excellence - if anything, I most often see "most users" used to guide the compromising of technical standards.
  - enneff 10y ago
    But Go doesn't perform abysmally. The 1.5 GC is technically excellent (ask an expert). Go does target "most users". That's the demographic. There will always be edge cases for which the general design does not work.
masklinn 10y ago
> Does anyone feel confident that a 'good enough for everyone' GC will ever be produced? Probably not, GC is always full of tradeoffs. That's why the JVM has a bunch of tuneable GCs, and there are third-party JVMs with their own strategies and GC tradeoffs (e.g. Azul).

oleganza 10y ago

GC highlight time-memory tradeoff at its worst because GC-based languages typically do not allow programmer to explicitly express his memory model forcing a lot of unnecessary "garbage" to be created. In Ruby all objects that do not fit in a tagged pointer are objects. In Go and Java some types are specifically optimized for being stack-based "value" types that reduces amount of work for GC. I personally like the "ARC" approach with ObjC and Swift where compiler statically adds and optimizes reference counting routines, promotes objects to stack when possible and requires programmer to manually resolve cyclic references (and Xcode supports nice methods to debug and visualize memory in order to detect unintentional cycles). Accidental memory cycles are rare enough and quite debuggable at a very little mental cost to mark some references as "weak" or "unowned". But the long-term performance and memory exhaustion issues caused by GCs are completely bypassed.

pjmlp 10y ago
The problem with RC as algorithm is that it increases locking on shared data structures, thus cache contention, and you still have "stop the world" when destroying a complex data structure causes a cascade of deletions. There was a Swift talk exactly about struct vs reference types and making use of COW data structures to reduce ARC impact.

ngrilly 10y ago

> Presumably the previous use cases are left behind No, they are not. The optimization discussed here adds something to the existing GC, and removes nothing. > Does anyone feel confident that a 'good enough for everyone' GC will ever be produced? The Go GC is constantly improving, and its performance in Go 1.6 and 1.7 is considered very good my most users.

vvanders 10y ago
There's a subthread further down that points to this exact type of regression: https://news.ycombinator.com/item?id=11970313 https://news.ycombinator.com/item?id=11970313 Without full memory control you're always going to making trade-offs in terms of performance. Hopefully the GC is "good enough" for your use case but there will never be a one-size fits all GC.
- enneff 10y ago
  FWIW that "regression" looks like a program that depends on particular runtime characteristics to generate "artistic" output. Not really the kind of issue you can realistically develop around. In almost all practical programs the new GC (in 1.5) was a significant win, or at worst no change.
madgar 10y ago
> The Go GC is constantly improving, and its performance in Go 1.6 and 1.7 is considered very good my most users. Also true of Ruby or PHP. Which perform abysmally. "Most users" needs aren't what we look for to define technical excellence - if anything, I most often see "most users" used to guide the compromising of technical standards.
- enneff 10y ago
  But Go doesn't perform abysmally. The 1.5 GC is technically excellent (ask an expert). Go does target "most users". That's the demographic. There will always be edge cases for which the general design does not work.

masklinn 10y ago

> Does anyone feel confident that a 'good enough for everyone' GC will ever be produced? Probably not, GC is always full of tradeoffs. That's why the JVM has a bunch of tuneable GCs, and there are third-party JVMs with their own strategies and GC tradeoffs (e.g. Azul).