| HN Mirror

Y	Hacker News new \| ask \| show \| jobs

by joelgwebber 4155 days ago

Here's my take on GC in games, FWIW. I'd be very leery of using a VM with a garbage collector for the entirety of a game. They can be fine (and are extremely common) in embedded scripting languages, but it can be far too difficult to control the size of outlier pauses when everything on the heap is subject to GC. As mentioned elsewhere in this thread, the JVM GC has had an enormous amount of effort put into it, and it's still an issue that poses problems for Minecraft, et al.

I'm far from proving this assertion yet, but I believe that Go's memory model allows for a middle way that will avoid big GC pauses. As I touch on briefly in the original post, you can use Go's C-like value types and pointers to field/elements to avoid generating garbage for large numbers of homogenous objects (e.g., by implementing a simple pool allocator), just like you'd do in C[++] to avoid heap fragmentation.

I hope to get more actual data on how this works as I expand my prototype, and will do follow up posts as I learn more.

2 comments

ANTSANTS 4155 days ago

I think you're right about Go's memory model helping a lot when compared to e.g. a typical dynamic language, but I have to ask: if you're going to be using manual memory management techniques like object pools and avoiding heap allocation whenever possible, what exactly does a garbage collected language buy you? I'm more of a C guy myself, but presumably RAII with smart pointers in C++ would get you most of the productivity benefits of garbage collection for the parts of the code that "don't matter" with much more reliable soft-realtime guarantees, while providing you with much greater memory management controls and optimization opportunities for the parts that do, and having far superior debugging support to boot.

link

joelgwebber 4155 days ago

C++ management can of course be workable with enough care. I worked on Chrome for a bit while at Google, and saw that it more or less holds together with enough reference counting and smart pointers. At the same time, it still requires a lot of care, and plenty of bugs have been caused by subtle mistakes in this kind of code (which is why Chrome uses a sandbox around the actual rendering engine, because it's far too complex to be trustworthy). But even Blink/Chrome is moving to a garbage collector (http://www.chromium.org/blink/blink-gc) for C++ objects because of all the memory management complexity.

What I'm hoping is that you can have a GC that allows you to avoid all these issues without having to be super-careful all the time, while mitigating the pause issue by reducing the garbage using pools and similar techniques. My hypothesis is that most of the little allocations that game engines perform are homogenous enough that moving them to pools will be fairly easy. And that this will be sufficient to avoid big pauses. But we'll see how it plays out in practice when I get some hard data on big scenes.

Finally, memory management isn't the only reason I'd prefer to avoid C++. I'm particularly sick of long compile times (they could really kill you on a big project like Chrome), and among other things I believe that Go's concurrency model will prove a big improvement over C threading.

link

ANTSANTS 4154 days ago

Interesting, thanks. The idea that Chrome is moving to garbage collected C++ is... a bit surprising to me, though I suppose it makes some sense given their focus on security.

I can see why you'd want to get away from C++'s compile times, though they're a lot more manageable if you can avoid templates like the plague. Have you considered a coroutine library for C or C++? I'm using libco right now for my hobby game project and much like "goroutines" would, it's significantly improving the clarity of a lot of systems (though of course I don't get the "free" parallelism because it doesn't handle scheduling across threads or anything like that).

link

joelgwebber 4154 days ago

To be precise, Blink is moving to a GC for stability (including avoiding leaks), but I don't believe it's for security -- the renderer remains sandboxed because it's effectively impossible to secure such a huge pile of C++ code. This presentation (which assumes a lot of familiarity with the WebKit/Blink smart pointers) goes into some interesting detail: https://docs.google.com/presentation/d/1YtfurcyKFS0hxPOnC3U6...

It includes particularly intriguing bits like "You can remove all on-stack RefPtr<X>'s. This is the biggest reason why Oilpan performs better than the current reference counting." I don't know whether that always holds true -- as of the middle of last year, I heard that they'd gotten to the point where most things perform roughly at parity, some worse, and some better. Keep in mind that this is an opt-in system -- if you don't use the smart pointers the GC knows about, it will ignore them (IOW, it's not some crazy conservative beast like the C++ Boehm collector). Also, my understanding is that, the vast majority of the time, Oilpan only runs when the event loop goes idle, which makes perfect sense for a browser, and has an obvious correlate in a game's simulation/rendering loop. I think they only walk the stack looking for pointers in rare cases.

It's not hard to imagine a hybrid world where you opt-in to GC'd pointers, but are free to use different allocators for performance-sensitive bits. This smells a little like Rust, but without the need to satisfy the lifetime checker thing.

Thanks for the pointer on libco. I'll definitely have a look at that. I've not written much C++ (apart from Chrome and a few odds and ends while at Google) in a long time, so it's quite probable I've missed some significant improvements on that front.

link

pjmlp 4155 days ago

There are a few German studios using Erlang and JVM languages for their MMOs on the server side.

link

sntran 4154 days ago

Do they have websites I can take a look?

link

pjmlp 4154 days ago

Wooga is using Erlang

http://www.wooga.com/

http://www.gdcvault.com/play/1016648/Why-Erlang

EA uses it as well