Skip to content
0:00 / 0:00

#garbagecollection#gogc#go1.5

GopherCon 2015: Go GC: Solving the Latency Problem - Rick Hudson

Gopher Academy

41K subscribers • 5 videos on Hallway

YouTube
  • Recommended by 2 people: 2 on Hacker News.
  • Presented by Rick Hudson, Go team member at Google

Intermediate. Assumes working knowledge.

21K views11 years ago2 recommendations

Programming languagesSystems programmingGoPerformance and optimizationConcurrency and parallelism

Rick Hudson explains how the Go 1.5 concurrent garbage collector achieves low latency and eliminates long stop-the-world pauses.

Long garbage collection (GC) pauses stand directly in the way of Go’s growth. It is an important, and often times the only, technical reason practitioners give for not migrating to managed runtimes such as Go. If Go is to live up to its promise of providing a better place for developers it must eliminate long GC pauses. This talk presents and discusses the new 1.5 low latency concurrent GC. Motivations will be given, performance numbers will be presented, we will deep dive into some technical challenges, but more importantly we will discuss why this approach fits well with the Go language.

Why it's here

2 people recommend this, 1 disputes it

What people say. Engineers point to this talk as the definitive explanation of Go's transition to a low-latency concurrent garbage collector.

shawnpson Hacker News • Recommends

On “Golang proposal: Dense mark bits and sweep-free allocation”

If you liked this you might also find Rick Hudson's talk on GC improvements in Go 1.5 interesting: link to this video link

kelseyhightoweron Hacker News • Recommends

On “Google Open Source Load Balancer in Go”

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/20161 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 23 1 link 2 link . 3 link to this video

deepsunon Hacker News • Disputes

On “Why Discord is switching from Go to Rust”

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 link to this video 2 link

u/faifacein r/ProgrammingLanguages • Mentions

On “Advantages of garbage collection over deterministic object lifetimes”

Oh yeah, this one is awesome: link to this video Goes in depth.

twotwotwoon Hacker News • Mentions

On “Go 1.6 GC improvements”

…arking 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 link to 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. T…

gizzlonon Hacker News • Mentions

On “The Path to Rust”

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: link to this video Edit: Meanwhile, over in Java land they measure stop the world pauses in seconds , not milliseconds: link link