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

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

#101

Post by arielb1 » Thu, Jul 09, 2015, 9:49 AM UTC

Skinney wrote: post #39

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 po…

You can write a doubly-linked list rather easily with `RefCell>`/`RefCell>`.

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

#102

Post by andrewchambers » Thu, Jul 09, 2015, 9:59 AM UTC

mseepgood wrote: post #71

felixgallo wrote: post #54

Earlier quoted context omitted.

ARC is pretty great, but it's still very possible to leak memory, and you can actually cause longer pauses when references go out of scope than well-tuned modern GCs can. So there's pluses and minuses, as in all things.

The "A" in ARC is a bit of an euphemism. You basically move the coding of your memory management into the type signatures, which don't write themselves automatically either. The amout of thoughts you have to make during development is the same.

I thought the A was for atomic, ARC is atomic reference count. RC is non atomic.

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

#103

Post by mseepgood » Thu, Jul 09, 2015, 10:54 AM UTC

andrewchambers wrote: post #102

mseepgood wrote: post #71

Earlier quoted context omitted.

The "A" in ARC is a bit of an euphemism. You basically move the coding of your memory management into the type signatures, which don't write themselves automatically either. The amout of thoughts you have to make during development is the same.

I thought the A was for atomic, ARC is atomic reference count. RC is non atomic.

https://en.wikipedia.org/wiki/Automatic_Reference_Counting

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

#104

Post by andrewchambers » Thu, Jul 09, 2015, 11:03 AM UTC

mseepgood wrote: post #103

andrewchambers wrote: post #102

Earlier quoted context omitted.

I thought the A was for atomic, ARC is atomic reference count. RC is non atomic.

https://en.wikipedia.org/wiki/Automatic_Reference_Counting

My mistake, in rust it is atomic, in objective c it is automatic.

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

#105

Post by the8472 » Thu, Jul 09, 2015, 12:31 PM 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…

One thing that's rather difficult to implement without GCs are concurrent, wait-free data structures.

When you have multiple threads trying to unlink structural elements they have to back off and leave the work to other threads, otherwise you will get contention on the pointers which breaks the wait-free guarantee.

With a GC you can just null out a reference. Or let another thread do the nulling.

With manual memory management you can only call free once. With ownership a thread cannot back off because it has taken ownership for that chunk of the data structure. With reference counting you either have contention from the count fields or vastly inflated footprint for striped counters.

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

#106

Post by rurban » Thu, Jul 09, 2015, 12:34 PM UTC

fauigerzigerk wrote: post #95

rurban wrote: post #69

Earlier quoted context omitted.

> I just don't really understand why people continue to work on garbage collection. > ... but I think it's time to walk away from GC Well, look at the arguments. GC advantages: * less memory (unless you use a semi-space GC) * faster * can handle cyclic refs (graphs, not only trees and linked lists) * trivial to use, less programmer errors What you got wrong: significant memory and CPU overhead. If you compare the mem…

Can you point me to the source of your claim about memory overhead? The Go team specifically states their goals for the 1.5 garbage collector as follows: "Hardware provisioning should allow for in-memory heap sizes twice as large as reachable memory and 25% of CPU cycles". http://llvm.cc/t/go-1-4-garbage-collection-plan-and-roadmap-... As far as I know, that collector is not a copying collector. I also know that all…

They are still using a simple and slow GC, non-copying, tri-color M&S, but at least incremental.

So they need to scan the complete heap, while a good copying collector (e.g. a two-finger Cheney with forwarding pointers) would only need to scan the stack and some roots. My GC needs ~4ms on normal heap sizes, the fastest M&S GC's need ~150ms. But I haven't found a good version besides the Azul one, which works fine threaded.

Memory overhead: A non-copying GC has none. Lookup a GC book or explanation. Refcounts have plenty: 1 word per object. malloc has plenty for its free-list management, growing with the heap size.

A semi-space GC is different as it reserves for every heap segment a mirror segment. A fast version reserves max heap and divides it by 2, so can use max 2GB of 4GB. A normal version can do that incrementally.

Java has a huge memory overhead from the kernel and run-time alone, not so the GC, but since they have various swappable GC's you need space for that. You can write better and smaller run-times with GC which do run circles around Java, .NET, Go or Ruby. As I said mine needs ~4ms, the fastest java is ~20 - 150ms. v8 has a good one, but I don't know their stats out of my head.

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

#107

Post by the8472 » Thu, Jul 09, 2015, 12:35 PM UTC

dboreham wrote: post #37

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, inabil…

> pauses

pause-less GCs have been proven possible

> I recall being told 15 years ago that I was "a dinosaur" for being skeptical about GC.

15 years ago we neither had today's GCs nor today's alternative solutions. Whatever informed your gut feelings back then might not really be all that relevant today.

For all the praise Rust gets, its advanced ownership model is fairly new in anything that even remotely approaches a mainstream language.

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

#108

Post by Skinney » Thu, Jul 09, 2015, 12:38 PM UTC

arielb1 wrote: post #101

Skinney wrote: post #39

Earlier quoted context omitted.

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 po…

You can write a doubly-linked list rather easily with `RefCell >`/`RefCell >`.

It's even easier in a GC based system.

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

#109

Post by the8472 » Thu, Jul 09, 2015, 12:42 PM UTC

derefr wrote: post #46

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'm just as confused as you are about most implementations of garbage collection. There's one that feels like it works, though: Erlang's. Erlang doesn't do anything different in its GCing algorithms or anything; it just gives each (really tiny) process its own heap, so there's lots of heaps, which can each be GCed at some opportune time when that particular (tiny) process isn't scheduled. It's stop-the-world GC, but…

> Generational, concurrent, real-time, whatever other clever properties: not important.

Those properties cut down the pause time in relation to the heap size. The more sophisticated your GC the larger your heap can be for the same pause time.

Until you reach the point where you have a fully-concurrent, pause-free GC.

Of course pause-free GCs aren't free lunch either. They incur increased memory traffic, require more CPU cycles per megabyte collected, require more headroom (i.e. larger memory footprint) to maintain their properties...

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

#110

Post by osi » Thu, Jul 09, 2015, 12:54 PM UTC

MrBuddyCasino wrote: post #96

rurban wrote: post #69

Earlier quoted context omitted.

> I just don't really understand why people continue to work on garbage collection. > ... but I think it's time to walk away from GC Well, look at the arguments. GC advantages: * less memory (unless you use a semi-space GC) * faster * can handle cyclic refs (graphs, not only trees and linked lists) * trivial to use, less programmer errors What you got wrong: significant memory and CPU overhead. If you compare the mem…

Also, Azul Systems solved that issue - the proprietary C4 GC has no pauses, and the heap can be huge, like hundreds of GB. If that tech would become common place, maybe this discussion would be obsolete. But I think C4 requires kernel support, and the first attempt to get a patch accepted didn't go well.

To clarify, Azul's Zing does have pauses, but they optimized the crap out of them (the pauses are more time-to-safepoint rather than GC pauses). GC time wrt application stopped time is constant regardless of heap size.

(I'm an Azul customer and Zing user)