Beware of drawing conclusions about generational GC from the Golang ISMM keynote. As far as I can tell, they didn’t test against copying generational GC with bump allocation in the nursery, which is the typical implementation.
-
-
-
Replying to @sgmansfield
How many non-copying generational GCs are actually deployed in the wild? I know of exactly one. All the others are copying.
1 reply 0 retweets 6 likes -
Replying to @pcwalton
"This is what everyone else is doing, therefore it's the right way?"
1 reply 0 retweets 0 likes -
Replying to @sgmansfield
Nobody has done benchmarks here, and in the absence of those I’m going to go with what’s been known for decades. Especially since there’s evidence that Go’s memory allocation is too slow for many people, since they manually rearrange code to satisfy escape analysis.
2 replies 0 retweets 10 likes -
Replying to @pcwalton
to satisfy your curiosity, you'd want an entirely new GC in the Go runtime? care to share the evidence you have?
1 reply 0 retweets 0 likes -
-
Replying to @sgmansfield
In favor of generational: SpiderMonkey switched from a malloc scheme to generational GC, to significant performance improvements. Most of the wins came from—you guessed it—bump allocation in the nursery.
1 reply 0 retweets 0 likes -
Yep, here’s a writeup with a simple benchmark. https://hacks.mozilla.org/2014/09/generational-garbage-collection-in-firefox/ … There’s lots of interesting stuff if you search for “spidermonkey generational gc” :)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.