6 ms·

I already asked here before but what is the status of the GC regarding real-time games? ( for a gameserver )

by Thaxll 12y ago

thecatspaw 12y ago
Minecraft seems to be doing okay. The key is to have many small GC pauses instead of few big pauses.
- rudolf0 12y ago
  Go is also completely overhauling their GC for the next release (1.5). See http://llvm.cc/t/go-1-4-garbage-collection-plan-and-roadmap-golang-org/33 http://llvm.cc/t/go-1-4-garbage-collection-plan-and-roadmap-...
- eropple 12y ago
  Minecraft's also had a ton of time invested into racing the beam with regards to the JVM GC. Not disagreeing with the viability of it, I personally use the CLR because I'm comfortable with that tradeoff and doing my work there too, but it is worth noting that a sufficiently complicated game will spend a lot of time dealing with memory issues. I'd use either the JVM or the CLR long before Go, though.
  - sehugg 12y ago
    The JVM also has probably the most man-years of effort into GC optimization. One thing the CLR has going for it is value types, which make arrays-of-struct possible (instead of arrays-of-refs-to-objects). I assume Go supports this too.
    - joelgwebber 12y ago
      See my earlier comment (and some bits of the original post). Go does indeed support arrays-of-structs, as well as taking pointers to the middle of arrays, and directly to struct fields. This gives you a lot more control over memory layout, and lets you avoid creating garbage if you're willing to put just a bit more work into it.
  - FreezerburnV 12y ago
    I think it's worth it to note that "a sufficiently complicated game will spend a lot of time dealing with memory issues" applies to all games. The memory issues might just be different. Or they could be simpler. Most games (especially large ones) tend to end up with multiple ways of garbage collecting eventually, even if written in pure C++. And that isn't even taking into account cache coherency, NULL pointers, double-freed pointers, etc. At least with something like JVM or CLR, you only have to fight the GC. Whether that's good or bad, that's left up to the developer fighting whatever memory issue is happening at the time.
    - jblow 12y ago
      It's bad. The reason is because you don't control the GC and don't even necessarily know what exactly drives the decisions it makes. So once you want to go beyond a certain level of performance, there is no right answer. You are just randomly trying stuff and kind of flailing. In C++ (or another direct-memory language), there is a right answer. You can always make the memory do exactly what you want it to, and there's always a clear path to get there from wherever you are.
      - eropple 12y ago
        > The reason is because you don't control the GC and don't even necessarily know what exactly drives the decisions it makes. I appreciate the flexibility and choice that a direct-memory language provides, but I think "randomly trying stuff and kind of flailing" is over-the-top. On the JVM you can control the GC quite effectively, with an understanding of the JMM and some experience its behaviors become largely predictable, and profile-directed memory optimization can be tedious, but certainly isn't random. Most Java developers I know are sometimes surprised by the JVM's behaviors...but then, most Java developers I know aren't terribly interested in how the JVM works. (My professional, non-game work is historically mainly on the JVM. I use the CLR for my game projects because even mobile platforms have an embarrassing surplus of performance relative to my needs and it's a lot more cross-platform than the JVM. I'm comfortable enough in C++, but I'm much slower at working with it--and I'm slow enough that I need all the help I can get!)
      - 12y ago
  - zamalek 12y ago
    > JVM or the CLR long before Go, though. Possibly only because they have been around for longer. The CLR 1.0 GC was a terrible beast. I'm sure that the earlier Java GCs were horrible things, too. > sufficiently complicated game will spend a lot of time dealing with memory issues. This is precisely why gamedevs are going for data oriented design, it all does come down to this at the end of the day. In theory a GC doesn't actually get in the way of DOD, because in the strictest definition it simulates infinite memory (it is, strictly, not a memory reclaiming device). GCs are getting better and better at doing this with less and less overhead. The newest concurrent CLR GC is pretty impressive, it very nearly never has to stop-the-world.
    - eropple 12y ago
      Sorry, I didn't mean to imply that I'd use them because of Go's garbage collector, which is vastly improved and arguably the best part of the entire ecosystem these days. I'd use the JVM or the CLR mostly because I am more convinced than I am about almost any technical topic that Go is a creeping, faddish horror that resists decent design practices for applications over a trivial scope, made by a team that took all the wrong lessons from Java and C++ and made a language worse than one or the other at almost every task that I can think of.
joelgwebber 12y 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.
- pjmlp 12y ago
  There are a few German studios using Erlang and JVM languages for their MMOs on the server side.
  - sntran 12y ago
    Do they have websites I can take a look?
    - pjmlp 12y ago
      Wooga is using Erlang http://www.wooga.com/ http://www.wooga.com/ http://www.gdcvault.com/play/1016648/Why-Erlang http://www.gdcvault.com/play/1016648/Why-Erlang EA uses it as well https://github.com/Eonblast/Emysql https://github.com/Eonblast/Emysql Blizzard / Activision / Demonware paper of Erlang http://www.erlang-factory.com/upload/presentations/395/ErlangandFirst-PersonShooters.pdf http://www.erlang-factory.com/upload/presentations/395/Erlan... As for Java, Deep Silver FISHLABS is using it http://www.makinggames.biz/features/the-backend-development-of-galaxy-on-fire-alliances,7051.html http://www.makinggames.biz/features/the-backend-development-... I have lost my Making Games magazines, so I cannot remember of the other names.
a-priori 12y ago
Java can be okay for soft real-time applications, like games, as long as you're very careful about the lifetime of your objects. The most recent versions of Hotspot, the most common JVM, has two memory pools for (non-permanent) objects: young and tenured. Objects start off 'young'; when they survive a few collections they become 'tenured'. Young objects are collected with a minor collection, which can happen concurrently with your code and doesn't stop the world. Old objects are collected with a major collection, which does stop the world. If you're writing a game, then minor collections are okay, but you want to avoid major collections at all costs. This means that it's okay to produce temporary objects that have very limited scopes; e.g., they're allocated while processing a frame/game step and are discarded immediately. It's also okay to produce objects that survive forever, because they won't become garbage. The problem comes in the middle, if you make objects that last a while (significant fractions of a second or longer) but eventually become garbage. They have a chance of becoming tenured, and will build up until they trigger a major collection. At that point your game will stall for a while. The other thing you'd want to change is to tell the GC to optimize for a maximum pause time with `-XX:MaxGCPauseMillis=<nnn>` (by default it optimizes for throughput). For a game server, a maximum pause of something like 500ms would probably be unnoticeable by players. More information: http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/toc.html http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gct...

I already asked here before but what is the status of the GC regarding real-time games? ( for a gameserver )

by Thaxll 12y ago

I already asked here before but what is the status of the GC regarding real-time games? ( for a gameserver )

thecatspaw 12y ago

Minecraft seems to be doing okay. The key is to have many small GC pauses instead of few big pauses.

rudolf0 12y ago
Go is also completely overhauling their GC for the next release (1.5). See http://llvm.cc/t/go-1-4-garbage-collection-plan-and-roadmap-golang-org/33 http://llvm.cc/t/go-1-4-garbage-collection-plan-and-roadmap-...
eropple 12y ago
Minecraft's also had a ton of time invested into racing the beam with regards to the JVM GC. Not disagreeing with the viability of it, I personally use the CLR because I'm comfortable with that tradeoff and doing my work there too, but it is worth noting that a sufficiently complicated game will spend a lot of time dealing with memory issues. I'd use either the JVM or the CLR long before Go, though.
- sehugg 12y ago
  The JVM also has probably the most man-years of effort into GC optimization. One thing the CLR has going for it is value types, which make arrays-of-struct possible (instead of arrays-of-refs-to-objects). I assume Go supports this too.
  - joelgwebber 12y ago
    See my earlier comment (and some bits of the original post). Go does indeed support arrays-of-structs, as well as taking pointers to the middle of arrays, and directly to struct fields. This gives you a lot more control over memory layout, and lets you avoid creating garbage if you're willing to put just a bit more work into it.
- FreezerburnV 12y ago
  I think it's worth it to note that "a sufficiently complicated game will spend a lot of time dealing with memory issues" applies to all games. The memory issues might just be different. Or they could be simpler. Most games (especially large ones) tend to end up with multiple ways of garbage collecting eventually, even if written in pure C++. And that isn't even taking into account cache coherency, NULL pointers, double-freed pointers, etc. At least with something like JVM or CLR, you only have to fight the GC. Whether that's good or bad, that's left up to the developer fighting whatever memory issue is happening at the time.
  - jblow 12y ago
    It's bad. The reason is because you don't control the GC and don't even necessarily know what exactly drives the decisions it makes. So once you want to go beyond a certain level of performance, there is no right answer. You are just randomly trying stuff and kind of flailing. In C++ (or another direct-memory language), there is a right answer. You can always make the memory do exactly what you want it to, and there's always a clear path to get there from wherever you are.
    - eropple 12y ago
      > The reason is because you don't control the GC and don't even necessarily know what exactly drives the decisions it makes. I appreciate the flexibility and choice that a direct-memory language provides, but I think "randomly trying stuff and kind of flailing" is over-the-top. On the JVM you can control the GC quite effectively, with an understanding of the JMM and some experience its behaviors become largely predictable, and profile-directed memory optimization can be tedious, but certainly isn't random. Most Java developers I know are sometimes surprised by the JVM's behaviors...but then, most Java developers I know aren't terribly interested in how the JVM works. (My professional, non-game work is historically mainly on the JVM. I use the CLR for my game projects because even mobile platforms have an embarrassing surplus of performance relative to my needs and it's a lot more cross-platform than the JVM. I'm comfortable enough in C++, but I'm much slower at working with it--and I'm slow enough that I need all the help I can get!)
    - 12y ago
- zamalek 12y ago
  > JVM or the CLR long before Go, though. Possibly only because they have been around for longer. The CLR 1.0 GC was a terrible beast. I'm sure that the earlier Java GCs were horrible things, too. > sufficiently complicated game will spend a lot of time dealing with memory issues. This is precisely why gamedevs are going for data oriented design, it all does come down to this at the end of the day. In theory a GC doesn't actually get in the way of DOD, because in the strictest definition it simulates infinite memory (it is, strictly, not a memory reclaiming device). GCs are getting better and better at doing this with less and less overhead. The newest concurrent CLR GC is pretty impressive, it very nearly never has to stop-the-world.
  - eropple 12y ago
    Sorry, I didn't mean to imply that I'd use them because of Go's garbage collector, which is vastly improved and arguably the best part of the entire ecosystem these days. I'd use the JVM or the CLR mostly because I am more convinced than I am about almost any technical topic that Go is a creeping, faddish horror that resists decent design practices for applications over a trivial scope, made by a team that took all the wrong lessons from Java and C++ and made a language worse than one or the other at almost every task that I can think of.

joelgwebber 12y 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.

pjmlp 12y ago
There are a few German studios using Erlang and JVM languages for their MMOs on the server side.
- sntran 12y ago
  Do they have websites I can take a look?
  - pjmlp 12y ago
    Wooga is using Erlang http://www.wooga.com/ http://www.wooga.com/ http://www.gdcvault.com/play/1016648/Why-Erlang http://www.gdcvault.com/play/1016648/Why-Erlang EA uses it as well https://github.com/Eonblast/Emysql https://github.com/Eonblast/Emysql Blizzard / Activision / Demonware paper of Erlang http://www.erlang-factory.com/upload/presentations/395/ErlangandFirst-PersonShooters.pdf http://www.erlang-factory.com/upload/presentations/395/Erlan... As for Java, Deep Silver FISHLABS is using it http://www.makinggames.biz/features/the-backend-development-of-galaxy-on-fire-alliances,7051.html http://www.makinggames.biz/features/the-backend-development-... I have lost my Making Games magazines, so I cannot remember of the other names.

a-priori 12y ago

Java can be okay for soft real-time applications, like games, as long as you're very careful about the lifetime of your objects. The most recent versions of Hotspot, the most common JVM, has two memory pools for (non-permanent) objects: young and tenured. Objects start off 'young'; when they survive a few collections they become 'tenured'. Young objects are collected with a minor collection, which can happen concurrently with your code and doesn't stop the world. Old objects are collected with a major collection, which does stop the world. If you're writing a game, then minor collections are okay, but you want to avoid major collections at all costs. This means that it's okay to produce temporary objects that have very limited scopes; e.g., they're allocated while processing a frame/game step and are discarded immediately. It's also okay to produce objects that survive forever, because they won't become garbage. The problem comes in the middle, if you make objects that last a while (significant fractions of a second or longer) but eventually become garbage. They have a chance of becoming tenured, and will build up until they trigger a major collection. At that point your game will stall for a while. The other thing you'd want to change is to tell the GC to optimize for a maximum pause time with `-XX:MaxGCPauseMillis=<nnn>` (by default it optimizes for throughput). For a game server, a maximum pause of something like 500ms would probably be unnoticeable by players. More information: http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/toc.html http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gct...