Go GC: Solving the Latency Problem in Go 1.5 • Hacker News Board

Re: Go GC: Solving the Latency Problem in Go 1.5

#31

Post by bjourne » Thu, Jul 09, 2015, 1:18 AM UTC

eggnet wrote: post #12

nulltype wrote: post #8

Earlier quoted context omitted.

Have you encountered any problems with go GC pauses?

Yes, I have. We used go in a system that had to keep track of essentially large hashes containing popularity / scoring information, in addition to what were effectively routing tables, and ran into >500ms pauses. At scale, it seemed the largest part of the complexity of go was manipulating data structures and code to avoid gc pauses. With sufficient work we may have been able to decrease the pauses sufficiently, but…

Why didn't you just use Java? Hotspot has been optimized for over a decade to make (among other things) gc pauses as manageable as possible. And there are other runtimes (http://www.azulsystems.com/) specifically optimized for low latency. The poor quality of Go's GC were never a secret.

Re: Go GC: Solving the Latency Problem in Go 1.5

#32

Post by arcticbull » Thu, Jul 09, 2015, 1:26 AM UTC

I've worked with garbage collected languages (ruby, Java, Objective-C in the bad old days), automatic reference counting (Objective-C and Swift), in the Rust model and manual reference counting/ownership in C over about 15 years now.

Having thought about this a lot, I just don't really understand why people continue to work on garbage collection. Non-deterministic lifecycle of objects/resources, non-deterministic pauses, huge complexity and significant memory and CPU overhead just aren't worth the benefits.

All you have to do with ARC in Swift and Objective-C is type 'weak' once in a while (which effectively builds a directed acyclic graph of strong references). With Rust you can get away with just structuring your code in accordance with their conventions.

I'm sure this won't resonate with everyone but I think it's time to walk away from GC. I'm curious, is there something I'm missing? The only true benefit I can think of is reducing heap fragmentation; and there must be a better way to address that.

Re: Go GC: Solving the Latency Problem in Go 1.5

#33

Post by arcticbull » Thu, Jul 09, 2015, 1:33 AM UTC

arcticbull wrote: post #32

I've worked with garbage collected languages (ruby, Java, Objective-C in the bad old days), automatic reference counting (Objective-C and Swift), in the Rust model and manual reference counting/ownership in C over about 15 years now. Having thought about this a lot, I just don't really understand why people continue to work on garbage collection. Non-deterministic lifecycle of objects/resources, non-deterministic pau…

To be clear, modern GCs are truly impressive -- I just don't think that GCs are how we should be addressing memory management. They impress me in the way that, let's say, a Rube Goldberg machine is an impressive way to make toast. I respect the craftsmanship, the creativity, the ingenuity ^_^ but I'd never make toast that way.

Re: Go GC: Solving the Latency Problem in Go 1.5

#34

Post by pcwalton » Thu, Jul 09, 2015, 1:43 AM UTC

arcticbull wrote: post #32

I've worked with garbage collected languages (ruby, Java, Objective-C in the bad old days), automatic reference counting (Objective-C and Swift), in the Rust model and manual reference counting/ownership in C over about 15 years now. Having thought about this a lot, I just don't really understand why people continue to work on garbage collection. Non-deterministic lifecycle of objects/resources, non-deterministic pau…

Modern allocators like jemalloc are very impressive at reducing heap fragmentation. In the non-moving-allocator world this is now almost a solved problem.

Re: Go GC: Solving the Latency Problem in Go 1.5

#35

Post by jzelinskie » Thu, Jul 09, 2015, 1:53 AM UTC

andrewchambers wrote: post #15

davidw wrote: post #3

Erlang's per-process (Erlang process, not Unix process) GC is pretty good from this point of view. I'm surprised they didn't mention it as something to think about.

Why would you mention it? Go is shares all memory, erlang doesn't. It is a different problem.

Actually, IIRC Erlang does have a shared heap, but it is used as an optimization to avoid copying very large objects.

Re: Go GC: Solving the Latency Problem in Go 1.5

#36

Post by kasey_junk » Thu, Jul 09, 2015, 2:04 AM UTC

arcticbull wrote: post #32

I've worked with garbage collected languages (ruby, Java, Objective-C in the bad old days), automatic reference counting (Objective-C and Swift), in the Rust model and manual reference counting/ownership in C over about 15 years now. Having thought about this a lot, I just don't really understand why people continue to work on garbage collection. Non-deterministic lifecycle of objects/resources, non-deterministic pau…

> The only true benefit I can think of is reducing heap fragmentation

Unless something has changed recently in the literature, concurrent data structures, especially lock free ones are super difficult to get right without garbage collection. Further, lock free structures are one of the most straight forward paths to large non-contended concurrent in memory data sets becoming the norm rather than the exception.

I'm am by no means an expert on this topic so its entirely possible the state of the art has changed on this, but that is the obvious case I thought of when asking the question about missing something.

Re: Go GC: Solving the Latency Problem in Go 1.5

#37

Post by dboreham » Thu, Jul 09, 2015, 2:29 AM UTC

arcticbull wrote: post #32

I've worked with garbage collected languages (ruby, Java, Objective-C in the bad old days), automatic reference counting (Objective-C and Swift), in the Rust model and manual reference counting/ownership in C over about 15 years now. Having thought about this a lot, I just don't really understand why people continue to work on garbage collection. Non-deterministic lifecycle of objects/resources, non-deterministic pau…

This is the one HN post that I agree with above all others. I also thought I was in a small majority holding this view. I recall being told 15 years ago that I was "a dinosaur" for being skeptical about GC. I'm now a black-belt JVM GC tuner but that has only served to confirm my feelings about GC. You're exchanging the solution of some albeit tricky problems for the acquisition new much worse problems (pauses, inability to reason about memory usage).

Re: Go GC: Solving the Latency Problem in Go 1.5

#38

Post by Skinney » Thu, Jul 09, 2015, 2:32 AM UTC

smegel wrote: post #23

RussianCow wrote: post #20

Earlier quoted context omitted.

Isn't that the point? Why else use abstractions if not to make yourself more productive?

Well if I asked your average brain-dead Java developer it would be to make your code more "generic" so you don't have to change a single line of code when requirements change, just tweak some XML somewhere! And if there is one thing that Java developers are not, it is productive. I will usually be finishing off a project in Python while they are still coding getters/setters on their AbstractProxyFactoryFactory class.

You're comparing libraries here. There are libraries in Java which are not over-engineered. That being said, even if all Java libraries were over-engineered, it would not make you correct. Correctly crafted abstractions makes you more productive.

Re: Go GC: Solving the Latency Problem in Go 1.5

#39

Post by Skinney » Thu, Jul 09, 2015, 2:37 AM UTC

arcticbull wrote: post #32

I've worked with garbage collected languages (ruby, Java, Objective-C in the bad old days), automatic reference counting (Objective-C and Swift), in the Rust model and manual reference counting/ownership in C over about 15 years now. Having thought about this a lot, I just don't really understand why people continue to work on garbage collection. Non-deterministic lifecycle of objects/resources, non-deterministic pau…

I tried making a double-linked list in Rust the other day. I found it hard to do without resorting to 'unsafe' code. I don't think a datastructure like HAMT would be a walk in the park either.

The thing about GC is that it makes it easy to write code. That's the main benefit. I don't want to deal with weak/strong references or ownership, just write code. True, a GC has downsides like increased memory footprint and possibly long pause times, but for most of the software I'll ever write it will never be a problem.

Re: Go GC: Solving the Latency Problem in Go 1.5

#40

Post by hueving » Thu, Jul 09, 2015, 2:44 AM UTC

arcticbull wrote: post #32

I've worked with garbage collected languages (ruby, Java, Objective-C in the bad old days), automatic reference counting (Objective-C and Swift), in the Rust model and manual reference counting/ownership in C over about 15 years now. Having thought about this a lot, I just don't really understand why people continue to work on garbage collection. Non-deterministic lifecycle of objects/resources, non-deterministic pau…

When you consider that most applications are just CRUD processors for some business logic that very rarely hit performance issues, the use case becomes obvious. GC saves developer time, which is the most significant cost for anything that isn't large scale.

The clerk at the front desk isn't meaningfully impacted if the backed has to GC for 350ms once in a while. But the clerk is impacted when his/her software is missing a ton of features because it was written in a language that exposed too many implementation details and led to the development budget running out.