I see this a lot. People assume that giving the game more leeway in terms of memory (RAM) usage makes it run better. This is actually not true, especially the common conception that “more ram = better fps”. So let me give you a somewhat technical explanation of why this is the case. I’m no expert in the matter either, but I believe I know enough to pass the knowledge around, so feel free to correct me if I mess something up.
Ok, so let’s start by talking about the Java Virtual Machine, and the concept of instance. TheJava Virtual Machine, as you might know is what’s responsible for running java applications, which obviously includes minecraft, when you load it up, it needs to know how much memory it can work with, this is what you change when you allocate more memory to the game, how much space it has to fill with anything the application needs to use. Next off is aninstance, in object-oriented programming, which Java falls under, an instance is, on very simple terms, an object, something that exists and has values. For example, the Minecraft game itself is an instance, created when you load up the world, which contains all the necessary data required to run the game. This data can be primitive, such as numbers or characters or complex, other instances. So the Minecraft instance would contain an instance for the world, one for the player, one for the render system, so on and so forth, each with a bunch more instances.
So why does this matter? Well, data takes up space. That’s just natural. The problem is that new instances are being created all the time. If a zombie spawns in your world, that’s an EntityZombie instance that’s created, every time you craft something, a new ItemStack instance. And these are on very high levels, every tick where you look at a block, a MovingObjectPosition instance is created so the game knows where you’re looking at, this requires usage of vector math, so there’s also some Vec3 instances being made. So new data is being created all the time. But… the amount of memory that’s allocated is finite, some space has to be made for this new data to fit, right?
Right. And that’s where the Garbage Collector (GC) comes in. It is basically a process that runs in parallell with your application, making sure space that’s being used up by the data of instances that are now obsolete and no longer needed (such as an Entity that’s no longer in the world, or an ItemStack that’s in no inventory any more, etc) is freed up to allow for new, important data. And here’s what it does, it always needs to make sure that there’s a good portion of the memory you allocated free, so if a bunch of new data comes along it has space to fit in, but it doesn’t do it actively, it doesn’t clear out memory as soon as the data becomes obsolete, it just does it every now and then. I’m not going to go into specifics as to when it does it, because I’m not experienced enough in the matter, but I know that the more memory you let it manage, the lazier it is. If you have 6GB of memory and only 2GB used, you really don’t care, there’s tons of space there, why bother, right? So the useless memory just piles up, and when you have a bunch all stacked in the corner it wakes up and goes “Woooooah, what’s all this!? Better clean it up!” as it grabs 3GB of trash. That’s 3GB of trash it has to clean up, that takes a while and a fair bit of effort, it’s naturally going to put some stress on your processor, and what does the user see during that time? A lagspike.
Of course if you don’t have enough RAM, the game simply won’t run as it won’t have enough space. And if you have very little you’ll have poor performance as the GC will be almost always busy trying to squeeze as much space as it can. So just try to find a good balance, it’ll pay off in the long run.
TLDR: Too much RAM lets java be lazy with clearing out unused data so you’ll get major lagspikes since the useless data piles up. Too little RAM will leave you with poor performance all around because java has to try to make space for new stuff all the time. Try to find a good balance.
Originally posted in Feb 3, 2015. Reposted due to server issues.