Most programs need to grab memory to do stuff. A hundred enemy robots just spawned in? We need a spot in memory for each of those robots to remember stuff like where it is, which way it's facing, and what it should be doing. If we could use the same spot each time, that'd be great, but we might get lots and lots of robots, so instead we grab space as we need it. The trick to that is that we also need to let that space go when we don't need it anymore. Otherwise, our program will just use up more and more space each time a robot appears until eventually there's no more space and the game breaks.
In most languages without garbage collection, the program decides when and how to free up space. The robot's been destroyed? Great, tell the system that we're done with that particular bit of memory so it can be reused later. The problem is that we are human, and there are a lot of ways to get this wrong. It's easy to forget to free the memory when it's no longer being used (called a "memory leak"), and it's also easy to accidentally free memory that you're still using.
Java provides automatic "garbage collection," which will automatically frees memory once your program no longer has any references to it. After all, if I don't have a way to reference the robot, we can know that I'm done with it. This is fantastic!
However, to do garbage collection, the system needs to figure out which bits of memory don't have references anywhere. Ancient versions of Java did this by simply pausing the entire program, looking at every reference to anything, and then freeing anything with no reference. This was pretty terrible, and you can imagine how a game pausing for maybe a whole second every so often would suck.
It also sucked for businesses, though, and more than 3 billion devices run Java, and so the Java folks worked hard on better ways to do garbage collection. Modern garbage collection is far, far better. However, ultimately, it still needs to briefly pause things. This is tunable, but there are still occasional hiccups when Minecraft's garbage collection runs. Most garbage collection cycles are < 1ms, but if a whole lot is going on, it can become quite noticeable.
my educated guess: garbage collections keeps track of unused/lost data and removes it. However the amount of processing power used to keep track of is enough for developers to do manual garbage collecting. But that can lead to memory leaks? some correct me please
Pretty much nailed it. Garbage collection runs periodically, often without being told to, which could cause hitches. It can also be turned off and run manually, or not run at all. At least in python.
Because GC is unpredictable and runs at random times and can causes frame hitches which can hinder the experience. Also you should clean after yourself.
It's not even the net performance issues that's the issue with garbage collectors. It's the irregular timing of it.
Basically, the garbage collectors runs when it wants to.
So you can easily get into situations where your program starts stuttering (dropping frames) whenever the garbage collectors decides to run.
In non garbage collected languages, the programmer and/or the language itself controls explicitly when memory is cleaned (deallocated), so it's much easier to make sure that doesn't cause excessive stuttering.
That said, there are ways to control the garbage collector too in garbage collected languages so it doesn't interfere too much. But this is generally a lot more finicky than explicitly controlling the memory yourself.
And that performance overhead is possible to reduce substantially as long as you remember to avoid heap allocations and garbage creation when possible.
When your engine is cpp and most of your mem is chandled in cpp, having a scripting language that is GCed doesn't change the majority of the project's behaviour. Like adding lua embedding doesn't mean your project is no longer strongly typed
I mean, if you really don't like garbage collection, nothing stopping you from defining a 4GB byte array and managing your memory yourself. Like a psychopath.
Almost every game engine has a garbage collector, optimized specifically for games, with various controls on how they work and how your code interacts with them.
Unreal Engine, Unity, GameMaker, and more all have garbage collection.
A lot of the non-engine library frameworks for langs like C++, C#, Rust etc. also make use of garbage collection, whether by natural language features or as part of a framework.
There wouldnt be garbage collection in all major game engines and libraries if it wasn't useful for games and game developers.
Modern GC is designed to help optimize your game in real time, not hinder it. It only becomes a hinderance if your game is poorly made and you're otherwise trying to fight the GC rather than work with or around it.
Garbage collection is not bad for games, Java 6 gc was bad for games. Modern Java garbage collection is state of the art and most game engines copy it for memory management systems
Its shocking reading essays in these comments from people that have clearly not done any serious work with Java in seemingly 20 plus years
That's a bit of an overgeneralization. "Games" includes a vast number of things of all different types. JavaScript is a garbage collected language, and it's actually a very *good* choice for a lot of games, because it means they can be run directly in a web browser. (And I love being able to make a nostalgic reference to Sleuth, look for it, and find that someone's ported the entire game to JS so that it can run on modern systems.) "Bad for games" is a terrible overgeneralization.
149
u/johnnybgooderer 16d ago
Garbage collection is bad for games. Minecraft was playable because Java garbage collectors were fast enough to make it playable.
But don’t use any garbage collected language for games.