Live data from Hacker News

Java’s new garbage collector promises low pause times on multi-terabyte heaps

opsian.com

241–245 of 245 posts

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#241
post #196

Earlier quoted context omitted.

I wonder if that would make java more suitable to game development since pauses need to be <8ms, ideally.

8ms? Where do you get that number from? If your player has a 144Hz monitor then your pause time, rounded to the nearest millisecond, has to be 0ms.

60hz displays, giving a frametime of ~16.667ms. 8 is around half that, giving you opportunity to drop a frame, but not much more that.

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#242
post #92

Earlier quoted context omitted.

Plenty of people are writing low-latency trading applications in Java where the latency budget is under 100 microseconds. This has been the case for several years now. It's by no means new or even especially difficult these days. The resulting code is far more maintainable and robust than C++ solutions.

I've had the opposite experience. For green-field applications, it's far easier to write the application in C++ than Java & meet the latency requirements. Java requires far too much tuning, where as C++, from the get go, you can generally just glance at the code and have a good idea of the latency. We're currently fighting a Java app that in general has decent latency (10s of usecs), but has outliers of greater than…

Oof. There's probably some compounding factors that make it more difficult, but usually getting GC pauses <500ms isn't that hard with current-gen collectors. Either being very careful with CMS, or just feeding G1 a lot of memory.

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#243

Earlier quoted context omitted.

I wonder if that would make java more suitable to game development since pauses need to be <8ms, ideally.

On smaller heaps it was already possible to get 5-10ms pauses with the (now deprecated) CMS collector. Unlike Z it was a non-compacting collector though and had some ugly worst-case behaviors.

Yeah, CMS is great until it isn't, and then it ruins your whole day. A bit of a black art to get tuned well, too, and when your workload changes slightly your tuning is no longer effective and the world stops for 30+ seconds. Hopefully ZGC will be more like G1 in terms of "feed it some extra memory and set a latency target" being all the tuning you need most of the time.

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#244
post #153

Earlier quoted context omitted.

Sounds interesting. Could you explain how so?

He's just trying to bash Java. HN readers hate Java for some reason.

It's not 100% wrong. "Everything is an object" comes with some extra memory overhead, plus some GC accounting. Most garbage collectors need a decent amount of "slack" space to avoid OOM or long STW collections as well. So, I could see Java needing 1.5-4x the memory of C++ pretty easily anyways.

Re: Java’s new garbage collector promises low pause times on multi-terabyte heaps

#245

An interesting fact is that the hotspot team went back on their 20-year conviction that load-barriers reduce performance too much. I guess improvements in CPU and VM designs has changed their minds. This is a big deal, and a major departure. I'm hoping this will improve things, this new architecture more closely resembles Azul's C4. Java and large heaps with non-conforming object allocation patterns (medium aged obje…

G1 does a lot better here in my (somewhat limited) experience. There's some overhead, and you have to give it some extra space, but the mixed collections are decent at making their way through medium-aged objects that survived to the old generation. Still nowhere close to 5-10ms though, and with a fair bit of memory bandwidth burned copying it through the survivor spaces.
Post reply on HN