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

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

opsian.com

Post reply on HN
Print view View original

201–210 of 245 posts

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

#201

Post by namibj »

hermitdev wrote: post #138
electrum wrote: post #98

Earlier quoted context omitted.

It's more about the memory layout than where the objects live. For example, consider a Point class with (x, y) members. If you have an array of these, each element in the array will be a reference/pointer to a separately allocated Point instance which can be anywhere in the heap. Accessing the array is expensive due to lack of locality (arbitrary memory access). Additionally, each instance has substantial object over…

Value types also give you more control over cache locality. Not having to travel that extra pointer redirection can really add up depending on what you're doing.

There is at least half a magnitude in speed benefit from a cache-line-size/alignment tuned B-tree compared to e.g. a red/black tree or similar, if used to 'only' store pointer-size value types, and even more if the value type takes up even less space. A case would be e.g. a float/int pair ordered by floats and used as a priority queue or such. That's an 8-byte-large value type. Though, it might, for that case, need to be doubled up if there is a uniqueness constraint on the integers associated with the floats. LLC cache pressure can be very real. I highly recommend perf stat -dd and perf top -g -e uops_executed.stall_cycles as well as the -e cycle_activity.stalls_ldm_pending. The former counts how long stalls happen, including those where instructions like DIV just take long to execute, the second counts stall events, i.e. one stall per load/store, not weighted for how long this stall event actually stalled the core. I'm pretty sure the former ignores cases where just one hyperthread stalls, but I'm not as sure for the latter. On Haswell and newer, unless using branch taken/not-taken profiling, I recommend setting perf config --system call-graph.record-mode=lbr before using perf top -g and perf record -g, as -fomit-frame-pointer binaries cause issues otherwise.

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

#202

Post by jblow »

vilhelm_s wrote: post #198
jblow wrote: post #196

Earlier quoted context omitted.

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.

Where do you get your number from? 1/(144 Hz) is 7ms. 1/(60 Hz) is 17ms.

I get my number from decades of professional game programming.

In a 7ms frame, you are spending most of that frame doing the work of rendering the actual frame (unless your game is so trivial that the GC is going to be easy / fast anyway). An additional millisecond is going to cause you to miss your deadline and drop a frame. Dropped frames feel really bad.

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

#203

Post by phakding »

hermitdev wrote: post #148
dnomad wrote: 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…

It's always going to be subjective. If you have people experienced in gc tuning, it's pretty easy to weed those gc outliers out. I am currently doing that for one of the applications for the company I work for. For me, it would be far easier to write a low latency, high concurrency Java app than a c++ app. The last c++ app that I was asked to write works horribly and bleeds memory. But it was not an important app.

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

#204

Post by Inityx »

simias wrote: post #145
felipemnoa wrote: post #140

Earlier quoted context omitted.

Sounds interesting. Could you explain how so?

Probably just a joke because of the tendency of Java applications (and other garbage collected languages to be honest) to consume an ungodly amount of RAM. Although these days I'd probably blame the web for that...

Not garbage collected languages per se; it's languages where data structures can't be value types[1], consequently consuming large amounts of extra memory because everything sits behind 2 or 3 or 5 layers of unnecessary 8-byte pointers.

[1] https://en.wikipedia.org/wiki/Value_type_and_reference_type

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

#205

Post by Scoping_dindus »

jblow wrote: post #202
vilhelm_s wrote: post #198

Earlier quoted context omitted.

Where do you get your number from? 1/(144 Hz) is 7ms. 1/(60 Hz) is 17ms.

I get my number from decades of professional game programming. In a 7ms frame, you are spending most of that frame doing the work of rendering the actual frame (unless your game is so trivial that the GC is going to be easy / fast anyway). An additional millisecond is going to cause you to miss your deadline and drop a frame. Dropped frames feel really bad.

I nearly spit my drink out from that dudes response, because I just happened to peek at your username as I was reading.

It's a crazy place here on HN.

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

#206

Post by gravypod »

jblow wrote: post #202
vilhelm_s wrote: post #198

Earlier quoted context omitted.

Where do you get your number from? 1/(144 Hz) is 7ms. 1/(60 Hz) is 17ms.

I get my number from decades of professional game programming. In a 7ms frame, you are spending most of that frame doing the work of rendering the actual frame (unless your game is so trivial that the GC is going to be easy / fast anyway). An additional millisecond is going to cause you to miss your deadline and drop a frame. Dropped frames feel really bad.

This sort of stalling is only caused by extremely short lived objects. Pooling and provisioning your data ahead of time goes a long way to fixing these specific issues to the degree that they become unnoticeable. There's a lot of tooling built into LWJGL to support this along with their own vector classes which are easily reclaimed.

Also has it really been a decade since Braid? Wow.

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

#207

Post by jblow »

gravypod wrote: post #206
jblow wrote: post #202

Earlier quoted context omitted.

I get my number from decades of professional game programming. In a 7ms frame, you are spending most of that frame doing the work of rendering the actual frame (unless your game is so trivial that the GC is going to be easy / fast anyway). An additional millisecond is going to cause you to miss your deadline and drop a frame. Dropped frames feel really bad.

This sort of stalling is only caused by extremely short lived objects. Pooling and provisioning your data ahead of time goes a long way to fixing these specific issues to the degree that they become unnoticeable. There's a lot of tooling built into LWJGL to support this along with their own vector classes which are easily reclaimed. Also has it really been a decade since Braid? Wow.

This is true, but it mainly just mitigates the problem. It can never solve the problem, because the whole concept of this kind of scheme is that the memory manager has some volition of its own ... thus it can choose to do things when you don't want or expect (actually this is unavoidable).

Also note that this category of answer is basically saying, "look, if you mostly manage your own memory, then GC takes less time!" That's true, but a large part of the value proposition of GC in the first place was to remove the burden of memory management. Once you are saying actually, GC won't do that for this class of application, then really what you are getting out of GC is memory safety (provided the rest of the language is memory-safe). On the one hand, hey, memory-safety is a benefit. On the other hand, I don't think very many people in game development would trade that much performance just for memory safety.

(And in fact in game development we very often have to do unsafe memory things. So really what ends up being said is "much of the system has memory safety" which, really, does not sound very alluring.)

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

#208

Post by AaronFriel »

chrisseaton wrote: post #191
negativegate wrote: post #189

Earlier quoted context omitted.

No, compression only works when you don't need to represent every possibility, or can use less bytes for some inputs and more bytes for others. https://en.wikipedia.org/wiki/Pigeonhole_principle#Uses_and_...

Why do you need to represent every possibility? You obviously aren't going to squeeze 2^42 objects into 2^42 bytes are you? They each take more than a byte. You don't need to address bytes individually. There's more holes than pigeons here.

Suppose we want to store 2^(48-n) 2^n byte objects in your hypothetical How do I compute the hash of every object, since by definition I can't address every byte?

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

#209

Post by [deleted] »

jblow wrote: post #202
vilhelm_s wrote: post #198

Earlier quoted context omitted.

Where do you get your number from? 1/(144 Hz) is 7ms. 1/(60 Hz) is 17ms.

I get my number from decades of professional game programming. In a 7ms frame, you are spending most of that frame doing the work of rendering the actual frame (unless your game is so trivial that the GC is going to be easy / fast anyway). An additional millisecond is going to cause you to miss your deadline and drop a frame. Dropped frames feel really bad.

[deleted]

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

#210

Post by jshap70 »

jblow wrote: post #207
gravypod wrote: post #206

Earlier quoted context omitted.

This sort of stalling is only caused by extremely short lived objects. Pooling and provisioning your data ahead of time goes a long way to fixing these specific issues to the degree that they become unnoticeable. There's a lot of tooling built into LWJGL to support this along with their own vector classes which are easily reclaimed. Also has it really been a decade since Braid? Wow.

This is true, but it mainly just mitigates the problem. It can never solve the problem, because the whole concept of this kind of scheme is that the memory manager has some volition of its own ... thus it can choose to do things when you don't want or expect (actually this is unavoidable). Also note that this category of answer is basically saying, "look, if you mostly manage your own memory, then GC takes less time!…

you've talked about that before, "we very often have to do unsafe memory things", and that a lot of things done in game dev end up violating a lot of principles that are taught in college, but to be honest I'm not sure. granted, I haven't worked directly in game dev before, but i've worked on some projects where runtime perf was the _only_ requirement... and I'm just not convinced that these issues couldn't be worked around using constructs like smart pointers, weak pointers, and just general design principles...

that said, the witness is one of my favorite games of all time, so I think its safe to say you know what you're doing

Post reply on HN