Hacker News Reader

Comment by jeffbee | Hacker News Reader

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 at the gRPC daily benchmarks if you want hard data. Java beats Go latency at the median and at the tail while having substantially better specific throughput. In other words the Java GC has no tradeoff versus the Go GC; it is better in every way.

View on HN

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.

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.

FWIW, I used to write some high-performance JavaScript. One of the tricks of the trade was to allocate early and make sure you avoid allocating once the loading phase has started, hence avoiding triggering the garbage-collector (in most runtimes/languages, gc phases are typically triggered by the allocator). This involved writing very non-idiomatic code, to a large extent reimplementing a form of high-level custom allocator on top of the existing allocator/gc, but it worked.

I'd be very surprised if the same wasn't possible in Java.

I don't know if this is how gRPC is written but it could explain an apparent contradiction.

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.

That’s neat, but a lot of applications will never need 16TB.

They are a beast in throughput as well (as well as alternatively, really really good at low-latency with the new GCs made specifically for that): https://news.ycombinator.com/item?id=29323468

Well, you are talking about java applications...

To be fair, early Java definitely had lots of issues with GC and "hanging" programs due to GC activity. It's a failure of the article to bring it up if modern Java implementation are better on that point. As an example of bad reputation, I think the latest Eclipse IDE on the latest Java SDK is still sucky and because of my ignorance I blame it on Java.

I was disappointed with the first Go gRPC implementation, it allocated like crazy and was really slow because of it. It's been rewritten since then but I don't know how much better it is now. To get good performance out of Go it is important to think about memory allocations (unfortunately), just as it is in C and C++. Although allocating like crazy in C/C++ will probably mostly result in a general loss of performance, not affect tail latencies in network protocols much.

gRPC Java wins in part due to not allocating memory when reading and writing buffers. It uses Java-based implementation of jemalloc (via Netty) to manage its own memory. No/low allocations means the GC doesn't need to wake up so much.

i've literally experienced worse pauses from java (sometimes surpassing 30s) GC due to allocation. granted it was pre the latest G1 GC. but they absolutely exist and many companies run on older versions of java.

and I doubt you see pauses in golang longer than 30ms. proof please.

Comparing apples to oranges. Java has been around for multiple decades so there may be some bias on your part based on very old examples, but also, your “average” java program is more likely much more complex and larger code base than your average go one.

Also, shitty code does get written by developers quite often, regardless of language — at that point the runtime can only do that much.

this is entirely BS. if by complex you mean overly abstracted and useless boilerplate then yes. java is larger and more complex.

and your assertion about the runtime only being able to do so much is just wrong here. golang will slow down your application in order to meet GC deadlines.

however its incredibly rare to see GC STW pauses for longer than 10s of ms. not even sure its possible given how the GC is written. this is true for heaps in the 100s of GBs.

this is why you don't hear about issues with golangs GC since like ~1.7. it just doesn't show up in 99% of use cases.

your basic assertion that java's GC is more advanced and therefor better is completely without merit. GC doesn't operate in isolation. java has more complicated GC systems because the language mandates them. golang entirely sidesteps the issues java has requiring said systems with better memory layouts and utilizing the stack.

its incredibly rare to hear stories about golangs GC because its simply not a problem.

java still has a bunch of issues and requires different GC tradeoffs as a result. meaning java will likely be in a constant state of 'which GC model do I use'

Have you followed this very thread?

> golang will slow down your application in order to meet GC deadlines

Hardly a good thing for throughput-oriented applications. Java let’s you tune this (the default G1 collector has a target pause time parameter, and then there is also the two new low-latency GC, Shenandoah and ZGC which has <1ms maximum pause time.)

> golang entirely sidesteps the issues java has requiring said systems with better memory layouts and utilizing the stack.

As mentioned many times, having value types greatly decreases the amount of created garbage, thus a less-modern GC can be enough for most Go applications. But there absolutely are use-cases where new object creation is unavoidable and java will beat Go by a huge margin, due to its more advanced GC, see:

https://news.ycombinator.com/item?id=29323468

> Have you followed this very thread?

indeed i am, people seem to having issues dealing with the reality of the two languages. One (golang) the problems you encounter with its GC are easily remedied using memory pools or adding compute. The other? you don't really have a choice without fighting against the language itself. or relying on improvements to the GC itself. which is precisely why java has had to spend so much effort on their GC to reduce latency while golang has been able to achieve extremely similar results with a fairly straight forward concurrent mark and sweep.

> Hardly a good thing for throughput-oriented applications.

add more compute. problem solved. its extremely rare to have situations where you can't add more compute to the problem. that's the point. you can easily solve throughput issues with compute. you can't solve latency issues as easily. if your STW GC pause ends up being 30s+ you're fucked. period.

if you're GC is the source of the problem because of garbage generation, generate less garbage. in go that's generally very easy. in java its very much not.

>beat Go by a huge margin, due to its more advanced GC, see:

you mean the advantage that entirely disappears with a memory pool added in like 4 lines of code? doesn't sound like a huge margin win to me.

I've never once asserted java's GC isn't amazing for the problem its solving. I'm asserting its completely unnecessary in golang because golang allows avoiding the garbage to begin with.

you: 'JAVA GC IS AMAZING COMPARED TO GOLANGS!' me: 'who gives a shit in practice golang memory allocation problems are trivial to resolve'

its the in practice of dealing with reality of the two languages I care about not the self inflicted problems java forces on developers.

Reply on news.ycombinator.com