GopherCon 2015: Go GC: Solving the Latency Problem - Rick Hudson
GopherCon 2015: Go GC: Solving the Latency Problem - Rick Hudson on HackerTube: recommended by 2 Hacker News commenters across 2 separate months, 2015–2020.
Rick Hudson's GopherCon 2015 talk on Go 1.5's new low-latency concurrent garbage collector. It covers the motivation, performance numbers, technical challenges and why the approach fits Go.
What HN commenters said
5 Hacker News comments link this video. Each one links back to its thread.
kelseyhightowerJan 2016Recommends
Go's TLS support should be greatly improved in Go 1.6 thanks to the performance work you referenced by Cloudflare. The licensing issue was resolved and the work was merged 11/10/2016[1] While GC will always carry a cost, great improvements have been made over the last year and continues to be an area of focus for each Go release. Rick Hudson gave a nice update on Go's GC improves at GopherCon 2015 [2][3] [1] [link] [2] [link] . [3] ▶ this video
in “Google Open Source Load Balancer in Go” · View on HN
shawnpsOct 2015Recommends
If you liked this you might also find Rick Hudson's talk on GC improvements in Go 1.5 interesting: ▶ this video [link]
in “Golang proposal: Dense mark bits and sweep-free allocation” · View on HN
gizzlonMay 2016Cites it
Oki, got it. Can't decide if that sounds like horrible conditions or a fun challenge =) For reference, the Go 1.5 GC propaganda: > Go 1.5, the first glimpse of this future, achieves GC latencies well below the 10 millisecond goal we set a year ago. Blog post: [link] Slide: [link] Talk: ▶ this video Edit: Meanwhile, over in Java land they measure stop the world pauses in seconds , not milliseconds: [link] [link]
in “The Path to Rust” · View on HN
twotwotwoAug 2015Cites it
It looks like a few things in there could further reduce typical and peak pause times, by backgrounding more phases of the work and rescanning stacks late so it's less likely much marking has to happen in the pause. I'm less clear on this, but "embrace write barrier during scan" and the other pacing changes might also better spread out work during the concurrent phases. The pause improvements in 1.5 are no joke -- here's a benchmark from the GopherCon talk on it: [link] (1.5 is the yellow dots along the bottom) (That talk is ▶ this video and the slides are [link] ) And here's a graph from a real-world memory hungry app on a beta--300ms pause down to 4ms: [link] (Presentation on that app here: [link] ) Another app's pauses went from ~12ms to ~2ms: [link] And this doc means Go isn't moving to a generational GC now, which the pre-1.4 proposal speculated they might do in 1.6. That would mostly be a throughput win (discard short-lived garbage cheaply and early, so full GCs can be rarer), not a pause win (it could add new short pauses for young-gen GCs). Seems sane for now, since the polish they're talking about seems difficult, directly useful, and important as a basis for future work, and the pauses seem like the larger headache for the working Gopher anyway.
in “Go 1.6 GC improvements” · View on HN
deepsunFeb 2020Critical
Wait, isn't Go devs said they solved GC latency problems [1]? (from 2015): "Go is building a garbage collector (GC) not only for 2015 but for 2025 and beyond: A GC that supports today’s software development and scales along with new software and hardware throughout the next decade. Such a future has no place for stop-the-world GC pauses, which have been an impediment to broader uses of safe and secure languages such as Go." [2] [1] ▶ this video [2] [link]
in “Why Discord is switching from Go to Rust” · View on HN