Hacker News Reader

Comment by babarock | Hacker News Reader

Unfortunately, as much as I want to agree with it, the article seriously lacks any credibility. Go claims to present high-level features (namely GC) for low-level system programming. Obviously, this sounds new and ground-breaking. Simply dismissing it on account that "GC is unacceptable [for low level problems]" is nothing short of stating a disbelief: it doesn't prove anything.

If anyone wants to prove any shortcoming, than maybe they should come up with a more technical analysis, or at least some sort of benchmarking.

View on HN

Do you seriously doubt that the Go GC is significantly worse than the Oracle JVM GC (by the metrics of pause times and throughput)? I don't think I've ever heard anyone suggest that it isn't.

My point with this article is simply that, even if Go's GC catches up to the JVMs (which would be an amazing accomplishment in itself), it would still be too inefficient for serious systems work. I provided several real-world examples to that effect.

If you want benchmarks, check out the numbers from moving some of the critical allocations off heap (and out of the GCs reign) in the Java HBase project: http://www.slideshare.net/cloudera/hbase-hug-presentation

In C, don't people just allocate a slab of memory for critical paths too?

Sometimes, perhaps, but simple malloc/free are much faster and more predictable than what you see in GC'd languages, often mitigating the problem. On top of that, many critical paths can avoid even those by confining their memory allocation to the stack, something that effectively ceases to exist in GC'd languages.

> but simple malloc/free are much faster and more predictable than what you see in GC'd languages

More predictable, very likely. Much faster, this is simply not true. E.g., quotes from an article by Brian Goetz[1]:

  The common code path for new Object() in HotSpot 1.4.2 and later is
  approximately 10 machine instructions, whereas the best performing
  malloc implementations in C require on average between 60 and 100
  instructions per call. ... "Garbage collection will never be as efficient
  as direct memory management." And, in a way, those statements are right
  -- dynamic memory management is not as fast -- it's often considerably faster.

> allocation to the stack, something that effectively ceases to exist in GC'd languages.*

Not true, either. With escape analysis, Hotspot JVM can do stack allocation. The flag of doing escape analysis is actually turned on by default now.

[1] http://www.ibm.com/developerworks/java/library/j-jtp09275/in...

That writeup is certainly interesting, mostly with regard to escape analysis, but it's entirely untrustworthy with regard to the comparison to malloc. First, it appears to base its assumptions about malloc implementations on a paper dating to 1993 (WTF?!), second is that it thinks "instructions" is a meaningful metric for judging performance.

malloc is not "much faster" than GC; it's often a performance bottleneck. That's why any C/C++ project worried about performance writes custom slab allocators, which a GC doesn't prevent you from doing. In fact, the GC frees you from thinking about memory management in most cases so you can focus your effort on optimizing the pieces that count. GC doesn't prevent stack allocation either; C# has explicit stack allocation and Java does it implicitly with escape analysis. The only advantage of malloc is its predictability. Hopefully Go will eventually get a pauseless collector to mitigate that concern too.

My understanding is that go still provides a lot of tools to indicate when you want memory allocated and where the memory will go (which can optionally be left out). If these were used, wouldn't that make it easier for the go gc to perform better?

It doesn't. Go provides stack allocation and heap allocation. Stack allocation is the default (except for some always-on-heap things), and stack allocation is silently converted to heap allocation when you take the address of an object.

Go's memory management story is basically the same as Java's with the "use escape analysis to place objects on the stack" flag enabled. (To be fair, there is one extra thing that Go provides: the ability to allocate objects inside other objects.)

IIRC the Go authors have explicitly said that there's probably a lot of low-hanging fruit for improving their GC implementation -- they were focused on getting something working and out the door.

Reply on news.ycombinator.com