Comment by geodel | Hacker News Reader

Comment by geodel | Hacker News Reader

Parent Full thread

Don't know about him but Gil seems happy by Go's choices GC area.

Here are Gil's view:

https://groups.google.com/forum/#!searchin/mechanical-sympat...

About Go:

"Go's GC story is evolving. And it's doing so at a fairly quick pace. Judging it based on a current implementation and current choices is premature, I think.

I think that the Go team's implementation priority focus on latency is a good one. And unlike others, I don't actually think there is a strong latency vs. throughput tradeoff in the long run."

And Kind words about Hotspot:

"The overall approach with HotSpot can be thought of as "start with a STW generational collector and increment your way to lower average/typical pauses in the old generations". E.g. all practical collectors in HotSpot use a monolithic stop-the-world copying newgen collector (not concurrent or incremental, monolithic, run-to-completion STW, always). And all collectors in HotSpot have a fallback to a full STW oldgen pause. The various non-monolithic-STW "cool modes" (Partially Concurrent non-compacting Oldgen in CMS, Incremental STW compaction in G1) are filters in the oldgen that occur between full STW newgen pauses and full STW oldgen pauses. They are "happy" when the filters work well enough to keep the STW newgen pauses in the tens of msec and delay the full-STW pauses for hours or days. And they consider it to be "ok and still working" even when those levels are not met."

You can check Shenandoah pause times (20-45ms) :

https://www.slideshare.net/RedHatDevelopers/shenandoah-gc-ja...

Decent for Java world but not really competing with Go.

To add they seem very critical of Generational GC:

"Generational GC pay a steep penalty for copying Data."

> About Go:

You neglected to add the rest of the comment, which refutes the rest of your post:

> I would predict that as Go's use application cases expand it's GC implementations will evolve to include generational moving collectors.

(Emphasis mine.)

> To add they seem very critical of Generational GC:

That's their LRU cache benchmark, which is an artificial benchmark testing the worst case for generational GC, as they point out later in the slide deck. The takeaway from this should not be that generational GC is bad in general.

I would like to add another choice quotation from that discussion.

"It is common to see early GC-based runtime implementations that do not move objects around succumb to an architectural "hole" that creates a reliance on that fact early in the maturity cycles. This usually happens by allowing native code extensions to assume object addresses are fixed (i.e. that objects will not move during their lifetime) and getting stuck with that "assumed quality" in the long run due to practical compatibility needs. From what I can tell, it is not too late for Go to avoid this problem."

Previously I was not concerned about the long-term outlook for Go's GC. It's low pause (with some pathological cases) and currently very inefficient. The long term plan had previously mentioned moving to a generational/moving collector in the future. Gil's endorsement was cheering.

But, Ian's comments on non-moving collector's on the Golang-nuts mailing list were alarming (and seemed technically confused). Time will tell.

> and currently very inefficient.

Inefficient compared to what? Does it lead to Go apps use more memory? more CPU? longer execution time? Because I haven't seen much difference in those respect. In Fact in general Go apps use 2-10 times less memory than Java.

Good question, my claim was _very_ vague. The current GC in Go is inefficient in its use of CPU.

Specifically because it uses a non-moving collector it has a sweep phase which frees each of the dead allocations.

In Java, or similarly .net, the use of a moving collector means that dead objects aren't freed. The live objects are moved out of the current memory region and the whole region is then 'free'. If you have few live allocations and lots of dead allocations in that region then your GC cycle is much more efficient.

I can't comment on memory usage experiences. I have written very careful Java programs that ran on the 64bit hotspot server in ~40mb or memory. I've written Java programs that used gigs, and I've written the same range in Go.

I would like to quickly note that I actually like the Go GC. I think they are on a very promising path to a potentially great GC. But they are also given to some public hyperbole which I find awkward.

More CPU time. By not having generational collection, Go pays an enormous throughput cost, not only in how long marking and sweeping takes, but also in how slow allocation is. Go tries to make up for this by using escape analysis, but HotSpot's allocation runs circles around Go's. It's literally like 3 instructions in HotSpot; for Go it's probably over 100.

Go will not be able to fix this without introducing generational GC (or global two-space copying collection, but nobody would do that). It's unfortunate that the Go developers seem to be digging in their heels over this choice. They should admit that their approach is wrong for usual apps and introduce generational GC (as Gil suggests).

Gil seems to be fine with Go's approach to low latency and making a prediction about future direction. And IMO regarding hotspot he doesn't seem too impressed with their lack of emphasis on latency.

As a GC developer someone might be more impressed by Java's cutting edge work but as an application developer Java (hotspot) approach to GC does not buy me anything more over Go.

In my development experience Java apps use more memory and its GC is less predictable.

I can't speak for Gil, but Go's approach to garbage collection—low pause times at the expense of absolutely every other thing you might want in a GC—runs contrary to the wisdom of pretty much everybody else who works in this space. That's why nobody else does what Go does.

What is absolutely every other thing? My Go programs run more or less in same time for similar processing, and use quite a bit less memory than Java along the way.

The production problems I commonly run into is rather unpredictable and very long GC pauses in Java.

Sweeping throughput, allocation performance, pause frequency, mark time, compaction (Java can move objects around instead of triggering OOM), cache behavior, etc. etc.

At this point I'd just be repeating Mike Hearn's excellent blog post, so I'll just link you there: https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...

Thanks. At this point it is clear you are not a Java developer and have no idea how Java actually behave in enterprise applications. You would just quote an article with no numbers but unsubstantiated claims.

The takeaway for me is low latency is way more difficult to achieve in Java. Also Shenandoah claims to be useful for trading/e-commerce/interactive/qos guarantees based service. This covers large range of applications typically developed in Java. And here Shenandoah is suppose to be better than other hotspot GCs.

Reply on news.ycombinator.com