Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go GC: Solving the Latency Problem in Go 1.5

sourcegraph.com

Post reply on HN
Print view View original

121–130 of 132 posts

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

#121

Post by pcwalton »

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.

Azul also sacrifices throughput over the HotSpot GC to achieve very low pause times—the overhead of a GC is not just in its pause times! There's no free lunch.

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

#122

Post by fauigerzigerk »

rurban wrote: post #118
fauigerzigerk wrote: post #117

Earlier quoted context omitted.

>Memory overhead: A non-copying GC has none Do you have any idea what could make the Go folks ask for "in-memory heap sizes twice as large as reachable memory"? This seems to be completely at odds with what you are saying.

Why? Reserving virtual memory has nothing to do with actual memory usage.

It would be great if they really mean virtual memory, but I very much doubt it as it makes no sense as a goal and is inconsistent with mentioning "Hardware provisioning".

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

#123

Post by _ph_ »

I am a bit surprised by most of the discussion here so far. Garbage collection has first of all one fundamental advantage: correctness. You are guaranteed never ever to have a pointer to a freed object and that any unreachable object does get freed. For almost all programs that get written, correctness should go over speed.

And speaking of speed, unless you require hard realtime behavior, garbage collection can be quite beneficial. A generational GC offers faster allocation times than any malloc based allocator, and the collection of the nursery generation is instantaneous in most cases. ARC has the overhead of counting for each referencing/dereferencing and while it might predictable about kicking in when killing a reference frees memory, the time required to free a given object completely depends on how much objects get consequently freed.

Furthermore, garbage collection helps to write clean code, as it is safe (and usually cheap) to allocate memory during a function call and return results referencing the memory.

Of course, badly written programs might perform badly with GC - but without the same kind of programs would just be a disaster. And most strategies for efficient memory usage used in non-GC languages (e.g. memory pools for certain objects) can and should be equally used in GC languages.

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

#124

Post by pjmlp »

pcwalton wrote: post #120
pjmlp wrote: post #85

Earlier quoted context omitted.

> I'm curious, is there something I'm missing? Working in large teams with disparate skill levels and high attrition, e.g. typical corporate jobs. Manual memory management never works, because there is always someone that does the wrong thing that leads either to blow ups or security exploits, that take experts days to weeks to track down. ARC is one step up, but requires deep knowledge of the code, where to place we…

> Manual memory management never works, because there is always someone that does the wrong thing that leads either to blow ups or security exploits, that take experts days to weeks to track down. This only applies to unsafe manual memory management. Not all manual memory management is unsafe. > Lifecyle of resources is very deterministic in GC languages, provided one uses the proper language constructs, such as usin…

> This only applies to unsafe manual memory management. Not all manual memory management is unsafe.

There is no such thing as safe manual memory management, by definition manual memory management is unsafe.

Assuming you are defending Rust here, if the compiler, e.g. a tool, is doing validation of memory management, it is no longer manual.

As such I don't consider compiler verified memory management as manual.

> ... file that two threads are holding onto, which you want to close when both threads shut down

Easy, use a region and close the file when all threads join it. Let the thread runtime help the GC manage the resources.

Similar solutions can be applied to other types of resources.

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

#125

Post by pron »

pcwalton wrote: post #119
pron wrote: post #77

Earlier quoted context omitted.

... and I'll ask you the same question I always do: in that case, adding predictable, low latency arenas to GC languages is much easier than using hazard pointers (which are really a form of GC) to non-GC languages. Why should RC ever be the default?

> in that case, adding predictable, low latency arenas to GC languages is much easier than using hazard pointers (which are really a form of GC) to non-GC languages. I disagree with that. I haven't seen "opt-out GC" work that well in practice. People use memory pools in GC'd environments to work around slow GCs, sure, but they're limited and have poor safety/ergonomics, as nobody wants to have to explicitly free data…

> I haven't seen "opt-out GC" work that well in practice.

RTSJ (realtime Java). I've personally used it in a missile-defense system and it works perfectly, with hard realtime guarantees.

As I've said before, in-memory data comes in four flavors: stack, arena, permanent and arbitrary. It's very easy to have all four in a GC language, as RTSJ does very effectively.

> A pervasive GC, however, imposes its costs and benefits on the entire language ecosystem.

I would say the same about RC. RC and GC are both really good for a specific environment (constrained and unconstrained RAM respectively) and pretty bad for the other. Adding arenas and permanent areas for GC environments is just as easy/natural as for RC/manual environments. And, again, you get RC + arenas which are great for constrained environments and pretty bad for unconstrained, and GC + arenas which are great for unconstrained and pretty bad for constrained.

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

#126

Post by nulltype »

Skinney wrote: post #92
eggnet wrote: post #63

Earlier quoted context omitted.

About half a gig resident memory.

So Go's GC spent 1ms per MB?

According to this graph: https://pbs.twimg.com/media/CJatKFQUkAE5qcR.png:large

It's about 0.3ms per MB, so 1ms isn't that different.

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

#127

Post by smegel »

bitmapbrother wrote: post #58
smegel wrote: post #23

Earlier quoted context omitted.

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.

Yes, Java developers still hand code their getters and setters. What era are you from, again? Also, those "brain dead" Java developers still write code that smoke your dog slow Python code regardless of how meticulously you hand crafted your code. So yeah, I would be bitter too.

> What era are you from, again?

Uh, the one following hordes of brain-dead Java developers hand-coding getters and setters?

> Also, those "brain dead" Java developers still write code that smoke your dog slow Python code regardless of how meticulously you hand crafted your code.

And is delivered 2 years later, requires 5 times more people and costs 10 time more to develop. And Python can be plenty fast if you use the right libraries.

> So yeah, I would be bitter too.

What do I have to be bitter about? I get paid well to write Python, C and Go on bespoke and interesting back-end systems and don't have to attend daily stand-ups with brain-dead Java developers and Oracle DBAs and listen to them duke it out over who's fault it is queries are running slow. No thanks.

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

#128

Post by sporkland »

hueving wrote: post #40
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 miss…

For simple stateless request/responae services I doubt restricting yourself to non-gc techniques like ref counting or other technique for managing objects with simple life times shouldn't be to difficult either. The benefit you'd get for this is avoiding sporadic gc pauces messing up your latencies and resorting to really nasty gc tuning.

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

#129

Post by throwa990323249 »

arcticbull wrote: post #57
throwa990323249 wrote: post #49

Earlier quoted context omitted.

ARC won't work when you cannot determine ahead of time where the cycle can end safely. Pretty sure for an interesting set of algorithms this is a problem. It's something I find annoying about some ARC/Rust enthusiasts: their belief that because they haven't found need for a GC, that there isn't one.

That's why we have the 'weak' keyword ^_^ I'm confident any algorithm you want to design for a GC world can be implemented in an ARC world, maybe with a tiny bit of tweaking. It's not that there's 'no need for GC' its just that there are many ways to solve a problem.

Your "confidence" is wrong.

Consider a graph which can have nodes added, and edges added or removed. Say you want to keep track of the part of the graph that is connected to a node.

You can't know ahead of time which references can be weak. So all must be strong and you will leak memory when a circular part of the graph becomes disconnected.

In general, garbage collection is a difficult problem that solves a lot. You can't trivially do without it. It's not just a tool of laziness.

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

#130

Post by throwa990323249 »

jonathanyc wrote: post #60
arcticbull wrote: post #57

Earlier quoted context omitted.

That's why we have the 'weak' keyword ^_^ I'm confident any algorithm you want to design for a GC world can be implemented in an ARC world, maybe with a tiny bit of tweaking. It's not that there's 'no need for GC' its just that there are many ways to solve a problem.

Obviously you could implement any algorithm using reference counting instead of garbage collection. The question is whether or not you really want to pepper your code with what is essentially manual memory management when necessary.

ARC languages are Turing complete, but some algorithms require more than just "peppering weakrefs" and actually require you to essentially build your own GC.
Post reply on HN