4 ms·
There is most likely none. Go team at Google would have enough real usage feedback from running Go systems in their massive data centers. They most likely find
by geodel 8y ago
There is most likely none.
Go team at Google would have enough real usage feedback from running Go systems in their massive data centers. They most likely find it reasonable with all things considered.
This debate about Generational GC is theoretical in nature, claiming Java GC design is universally applicable irrespective of language and its use cases.
There may indirect approval to Go approach by Java when developing value types:
http://openjdk.java.net/jeps/169 http://openjdk.java.net/jeps/169
key Quote:
"In modern JVMs, object allocation is inexpensive, with a cost comparable to out-of-line procedure calling. But even this cost is often a painful overhead when compared to individual operations on primitive values. Thus, Java programmers face a binary choice between existing primitive types (which avoid allocation) and other types (which allow data abstraction and other benefits of classes). When they need to define small composite values such as complex numbers, pixels, or pairs of return values, neither approach serves. This dilemma often has no good solution, and the workarounds distort Java programs and APIs. "
If we go by claims that Java and its GC supporters always made:
1) RAM is Cheap 2) GC is incredibly fast so as not to worry about allocation.
There should be no need to waste tremendous multi year engineering effort to add value types to Java.
- openasocket 8y agoThat's a straw man. Just because GC is fast doesn't mean it can't be made faster. > Go team at Google would have enough real usage feedback from running Go systems in their massive data centers. They most likely find it reasonable with all things considered. That's not just an appeal to authority, that's a big assumption. As far as I know, no Go maintainer has claimed that they have gathered large amounts of performance data and concluded that a generational GC wouldn't improve performance. Also, calling generational GC "Java GC design" is disingenuous. Generational GC long precedes the creation of Java, and is used almost universally. Common Lisp (various implementations), .Net, the Lua VM (and the LuaJIT VM), BEAM, SELF, and Haskell (GHC at least) all use generational garbage collection. In fact, the current Go implementation is the only GC implementation I'm aware of that isn't generational.
- geodel 8y agoI think it is other way round. No one has yet shown in production applications that Go's GC throughput is big problem for them.
- pcwalton 8y agoThe question to ask is: Have people switched away from Go for certain applications in order to get better CPU-bound performance? Yes, they have. GC throughput is one part of the reason why Go code is often suboptimal for CPU-bound workloads. Adding a generational GC won't solve this, but it's bound to help.
- weberc2 8y agoI don’t think “has anyone ever switched from Go...” is particularly meaningful. Is the switch common? I’ve only heard of a handful (like 3) of cases where people tried optimizing Go and found it to be lacking, and those cases were at the extreme end of the performance spectrum. Also, Go will never be optimally performant because it chooses to balance performance with competing concerns (safety, simplicity, etc), so its unclear in those cases whether the suboptimalism was due to Go’s GC scheme or to other trade offs.
- yoklov 8y agoNeither Lua nor LuaJIT use a generational design, they're both tri-color incremental mark and sweep collectors without a separate nursery. There was a plan for a generational GC for LuaJIT [0] (not to mention a lot of other cool features and a very clever design) but it was never implemented (and at this point it probably never will be). [0] http://wiki.luajit.org/New-Garbage-Collector http://wiki.luajit.org/New-Garbage-Collector
- weberc2 8y agoAlso, most of the listed languages don’t have value types or added them expressly because their GC scheme was insufficient.
- pcwalton 8y agoIt does not follow that, because value types allow heap allocation to be avoided in some cases, it's not worth investing in making heap allocation faster. That's why I made the observation upthread to begin with.