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

Go does not need a Java-style GC

erik-engheim.medium.com

Post reply on HN
Print view View original

21–30 of 226 posts

Re: Go does not need a Java-style GC

#21

Post by remexre »

IceWreck wrote: post #14
Yoric wrote: post #11

Earlier quoted context omitted.

As a Rust developer, contributor and generally a big fan of Rust, I'd tend to disagree. Having a garbage-collector is a lifesaver for many algorithms. Static lifetime management is great but isn't something you want to force developers to use when they're more interested in coming up with solutions quickly. Also, I really don't see how it would work in Go. You require a pretty strong type system to make static lifeti…

> You require a pretty strong type system to make static lifetime management work Go is strongly and statically typed.

Rust's lifetimes need full subtyping, with covariant and contravariant type constructors (though I don't think it supports annotations for them, and always infers them instead), which I think would make the generics implementation quite a bit more complicated than it currently is...

Re: Go does not need a Java-style GC

#22

Post by Thaxll »

jeffbee wrote: post #17
Thaxll wrote: post #15

Earlier quoted context omitted.

The Java gRPC SDK is heavily optimized by Google, much more than the Go one. Until recently Java pauses were a real issue, I worked with a lot of Java based solutions ( elastic search, hadoop etc ... ) and was never impressed by the GC.

Maybe, but it's still not possible that the Java test has a median latency of 150µs, a tail latency of 350µs, and a regular need to stop the world for hundreds of milliseconds. That statement is simply not compatible with reality.

As I said the Java SDK is heavily optimized to do the least minimum of allocations. I mean if you don't allocate much the GC is not really an issue.

Re: Go does not need a Java-style GC

#23

Post by kaba0 »

JulianMorrison wrote: post #9
seunosewa wrote: post #2

I'm cautious about believing this sort of claim because I remember reading about why Go doesn't need generics, yet here we are waiting for Go Generics to be ready. However, the article convincingly explains who Java has a greater need for a compacting GC - it creates more garbage. This doesn't necessarily mean Go won't benefit from having a generational, compacting GC at some point, for some applications.

Go creates less garbage and also stack allocates things using escape analysis which as the article explains, is effectively a form of generational garbage collection.

As far as I know (I’m not too familiar with Go), Go mostly stack allocates based on the developer’s intent, eg. by using structs.

Java doesn’t (yet) have an option for value types that can be reliably stack allocated, so it resorts to very complex escape analysis. Calling the former escape analysis is a bit misleading imo, even if technically true.

Re: Go does not need a Java-style GC

#24

Post by papercrane »

avita1 wrote: post #10

Cool article, I'm not sure I agree with the headline. I used to write low-scale Java apps, and now I write memory intensive Go apps. I've often wondered what would happen if Go did have a JVM style GC. It's relatively common in Go to resort to idioms that let you avoid hitting the GC. Some things that come to mind: * all the tricks you can do with a slice that have two slice headers pointing to the same block of memo…

Object pooling in Java used to be fairly common. I don't see it much anymore in new code, but used to run into it all the time when writing code for Java 1.4/5. Even Sun used pooling when they wrote EJBs. Individual EJBs can be recycled instead of released to the GC.

Nowadays the GC implementations are good enough that's it's not worth the effort and complexity.

Though now that I think about it Netty provides an object pooling mechanism.

Re: Go does not need a Java-style GC

#25

Post by vore »

kaba0 wrote: post #23
JulianMorrison wrote: post #9

Earlier quoted context omitted.

Go creates less garbage and also stack allocates things using escape analysis which as the article explains, is effectively a form of generational garbage collection.

As far as I know (I’m not too familiar with Go), Go mostly stack allocates based on the developer’s intent, eg. by using structs. Java doesn’t (yet) have an option for value types that can be reliably stack allocated, so it resorts to very complex escape analysis. Calling the former escape analysis is a bit misleading imo, even if technically true.

Go is a little more elaborate than that: if a value is initialized as a pointer-to-struct (e.g. foo := &Foo{...}) and it doesn't escape the function, Go will allocate it as if were a value type.

Re: Go does not need a Java-style GC

#26

Post by masklinn »

JulianMorrison wrote: post #9
seunosewa wrote: post #2

I'm cautious about believing this sort of claim because I remember reading about why Go doesn't need generics, yet here we are waiting for Go Generics to be ready. However, the article convincingly explains who Java has a greater need for a compacting GC - it creates more garbage. This doesn't necessarily mean Go won't benefit from having a generational, compacting GC at some point, for some applications.

Go creates less garbage and also stack allocates things using escape analysis which as the article explains, is effectively a form of generational garbage collection.

However it's a weak one, the stack allocation acts as a form of extremely limited nursery, but lots of "escaping" objects could well fit into a nursery, to say nothing of "heap" objects (like strings and slices) which always trigger heap allocations.

Furthermore AFAIK most generational GCs have 3 generations, not 2 (let alone 1.5).

It does make the tradeoff more complicated, a generational GC is not simple (especially in a language with ubiquitous mutability), but the casual dismissals are... troubling.

And that's before mentioning the regularly problematic lack of tuning knobs of the Go GC, also often dismissed as "java concerns" (which Go users have to work around using ugly hacks when hit, because they don't have tuning knobs).

Re: Go does not need a Java-style GC

#27

Post by kaba0 »

Thaxll wrote: post #15
jeffbee wrote: post #12

There are very few falsifiable statements in this article but the extant ones are all demonstrably false, starting with this whopper: "This typically causes Java programs to have complete freezes of several hundred milliseconds where objects get moved around" Yeah, i mean, definitely not. The only language I regularly work with that has this property is, surprise, Go. The proof is in the tasting, as they say. Go look…

The Java gRPC SDK is heavily optimized by Google, much more than the Go one. Until recently Java pauses were a real issue, I worked with a lot of Java based solutions ( elastic search, hadoop etc ... ) and was never impressed by the GC.

While I agree that the java gRPC lib is better maintained, I don’t agree with your second point. Java’s GCs are the state of the art, that can manage heap sizes up to 16 terabytes. Other GC implementations would simply die there.

Re: Go does not need a Java-style GC

#28

Post by Yoric »

remexre wrote: post #21
IceWreck wrote: post #14

Earlier quoted context omitted.

> You require a pretty strong type system to make static lifetime management work Go is strongly and statically typed.

Rust's lifetimes need full subtyping, with covariant and contravariant type constructors (though I don't think it supports annotations for them, and always infers them instead), which I think would make the generics implementation quite a bit more complicated than it currently is...

Yeah, the fact that co/contravariant type constructors aren't (or aren't always?) annotated has always felt a bit awkward to me. Ah, well, it works :)

Re: Go does not need a Java-style GC

#29

Post by jeffbee »

Thaxll wrote: post #22
jeffbee wrote: post #17

Earlier quoted context omitted.

Maybe, but it's still not possible that the Java test has a median latency of 150µs, a tail latency of 350µs, and a regular need to stop the world for hundreds of milliseconds. That statement is simply not compatible with reality.

As I said the Java SDK is heavily optimized to do the least minimum of allocations. I mean if you don't allocate much the GC is not really an issue.

OK but again, that is a statement totally contrary to the article. The article is claiming two things: that it is easier in Go to avoid the heap while Java is utterly dependent on allocating everything on the heap - which is not consistent with the experience of actual Java and Go programmers - and that Java has a "preference for high throughput and high latency" which it doesn't.

Re: Go does not need a Java-style GC

#30

Post by munificent »

avita1 wrote: post #10

Cool article, I'm not sure I agree with the headline. I used to write low-scale Java apps, and now I write memory intensive Go apps. I've often wondered what would happen if Go did have a JVM style GC. It's relatively common in Go to resort to idioms that let you avoid hitting the GC. Some things that come to mind: * all the tricks you can do with a slice that have two slice headers pointing to the same block of memo…

> Both are technically possible in Java, but I've never seen them used commonly (though in fairness I've never written performance critical Java.)

I don't know about the Java world, but in C#—especially in games written in Unity—object pooling is very common.

Post reply on HN