I have this problem, where if I set render distance to "Far" Java exceeds 1GB of RAM on anything other than a regular old map. I used to be able to get around this by just scrapping any snow map I got when generating, but with biomes this is not a valid solution. The problem is that when Java does this, it stops working: It freezes and Windows tells gives me an error message. I'm pretty sure it's because either 1) Java is only allowed 1GB of RAM and does not do a dump automatically when it's reaching this limit or 2) because the engine is programmed specifically to only handle this much.
Therefore I ask you: Am I the only one experiencing this problem? And is there any way in which I can allow or force Java to use more RAM?
I have the same setup, same OS, but can't seem to make it use more than 1 115 000 KB memory.
Far fog setting, running around exploring even during nighttime, I see memory climb steadily. At around the 1mill mark, I hear the systemdisk working slightly (pagefile, perhaps).
Silly idea: Is your pagefile by any chance disabled?
Another idea: Completely uninstall java, then re-install it.
Simpler idea: Does this happen on only one specific world, or on any world?
Java lets you tell it how much RAM to use. By default on most PCs it would use 256MB, but the Minecraft launchers sets it to 1GB. Normally you set the heap size (as it is called in Java) like so: java -Xmx2048M -jar Minecraft.jar
That would set the heap to 2GB. Unfortunately that only sets the heap size for the launcher. That then starts another process with different options, and unless Notch changes the launcher there is no way to pass other options through.
Minecraft uses a "launcher" class which doesn't do anything except create another process which is the actual game. You can see this by the way the command line immediately returns when you run the command. The child process created by the launcher doesn't inherit any Java options from the launcher.
Check it out, if your using the Windows Launcher. Basically, the exe we use is only a wrapper. You can pass variables to the executable through a config file placed in the same directory as your Minecraft exe. Problem is, you can only designate a max of 1/4 of your RAM, minus operating system usage. This is a Java thing...
For instance, I use 8GB of DDR2-1066. The max I could designate without slowdowns or crashing was 1350M, or 1.35GB. That little bit helped so much though, as I got no more stuttering, freezes, etc... not sure why, but it helped.
Problem is, you can only designate a max of 1/4 of your RAM, minus operating system usage. This is a Java thing...
I wouldn't say "this is a Java thing". I assume that you are on a 64bit OS given the amount of RAM you have, so you should be able to uses many GBs without trouble. Though GC pauses can have an effect with larger heap sizes. The CMS GC option I mentioned in the previous post might help. Also on 64bit systems you can try -XX:+UseCompressedOops
Hmm, didn't know about GC. I tried setting my RAM to about 1.75Gb, but I would get horrendous freezing just trying to load the launcher. From what I was gathering from other threads about the issue was that the RAM issue was a Java problem, but no one could provide a reason as to why. I did try using a full 2GB at one point, but kept getting some error when trying to launch Minecraft - wasnt a MC error, but a JavaW error.
Once I get out of this programming class in 30 minutes, I will test your suggestion and post back with results.
The 1/4 of RAM doesn't apply to my computer, I have 2GB of RAM but get flawless performance with the default setting of 1024Mb max, provided I have that much free of course as disk swapping will kill any performance.
Not the same computer as used in the test above btw. I think I may have to bring some more RAM home from work and play a bit with the settings tonight maybe.
Good find on the .ini btw, that's a nicer way of doing it than making a shortcut to javaw. I'll probably do it from the command line while experimenting though.
Right, I have figured out that the Minecraft launcher behaves differently when the heap size is set. If it is too low then it launches another process which is why I couldn't change system properties before.
Be careful increasing the heap size if you have integrated graphics (particularly Intel): it can make the drivers crap out.
If Minecraft is slow instantly with a large heap size then I would guess the OS is swapping immediately. Are you sure you have all that RAM? And you are on a 64 bit OS? Actually maybe you have a 32bit JRE. That would explain why you can't go above 2GB. You can get a 64bit version at java.sun.com.
I got Minecraft to run with the server VM. For those who are not familiar with Java there are two "internal" versions of Hotspot: client and server (or C1 and C2). Client starts faster but doesn't optimize as much. Server takes a bit longer to start but can perform much, much better for long running applications. You turn on the server vm by adding -server to the command line. Unfortunately on Windows the JRE only comes with the client VM. To enable it you need to download and install the JDK (it is the Java development kit), go to C:\Program Files\Java\jdk1.6.0_22\jre\bin (or Vista/7 equivalent) and copy the server folder to C:\Program Files\Java\jre6\bin
It has the potential to help a lot if you are CPU bound. If you have crappy integrated graphics then it won't do much.
Actually maybe you have a 32bit JRE. That would explain why you can't go above 2GB. You can get a 64bit version at java.sun.com.
That's one well worth checking out. When I started looking at my Java environment because of some small performance issues with Minecraft I noticed I was running 32-bit Java only. Now running 64-bit.
Does anyone know if running 64-bit Java in itself would help performance (memory issues aside), like in more efficient running of the code or something to that extent? Or is that dependant on Notch also doing something with his code?
EDIT: Good info in general btw, will have to check some of this out. I already have the SDK installed.
Huh, didnt even notice that I am using Java 32bit - slightly annoying. Updating now, will post results lol. I know I said I would before, but didn't even cross my mind there, since the standard java installer never gave me the option, thus making me think it auto-detects, as with some software.
Give you an idea on my system, since I was getting oddly bad performance before increasing the memory...
x86 64 bit processors have a lot more registers available (x86 has very few registers compared to pretty much any architecture) which is the biggest performance advantage for 64 bit. 64 bit Java will take advantage of this automatically. There is a downside that pointers are now twice as big so you use more memory. In Java this can be avoided by using -XX:+UseCompressedOops, which does some extra work to make it possible to store pointers in 32 bits. Be aware that there have been many JVM bugs with this option.