And that would ocupy 2.5 gigs if im no wrong right, can i then run a client on the same machine with 512megs?
JVM Arguments for Modded Minecraft (Updated 12/30/13)
- Thread starter Eyamaz
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
Hey Eyamaz, i was looking into Mystcraft wiki, and they put some recommended Java Arguments. Here is the link http://binarymage.com/wiki/doku.php?id=setup:memory, is this really have effects? or maybe you can add some extra arguments to your OP?
Those are very old and were created for java 6, but yes I've seen them. An example of the outdatedness is that compressedoops is on by default in 64bit java 7 (at least with oracle, apple keeps screwing up their java implementation from what I've been seeing.) How I have mine setup is more memory intensive specifically for the massive modpacks we are now seeing. There are similarities and a few JVM arguments we both use.
Oh so it is a bit useless then? Well i am using it till now and i felt slight increases in performance. Maybe values different on some arguments?
Sent from my HTC Sensation using Tapatalk 4
Not useless, no. They still can give a bit of a performance increase. They are just designed differently than mine. For example, I don't recommend a compilethreashold lower than 1000 with any of the modpacks we see now. They are to large and it will force JIT into interpreter only mode with a lot of methods compiled that don't need to be. Something I avoid with my setup.
Wow... 1GB permgen, 2GB codecache 
That looks gigantic. How much of a performance hit would you take if you reduced these numbers? And what are the JVM defaults (when the arguments aren't set)?
Reason I'm asking: my new 4 GHz Haswell quadcore, 16 GB RAM desktop just smiles mildly at those values even with both client and server running, it just has that much in reserves. However, the usage of JVM arguments to boost performance on such a system is limited in the first place, because performance is already very high.
On the other hand, older systems desperately need any bits of extra performance they can get. Sometimes I invite friends over for some local LAN play, and they generally show up with clunky old laptops that struggle to get good FPS. Your suggested JVM arguments won't work for them simply by virtue of not having that much memory to invest. Do you maybe have a recommendation on what to do on a computer with only small amounts of system memory installed? 2GB, 4GB? Heck, some people are limited to odd ~3GB by virtue of a 32bit operating system...
EDIT: Yeah, maybe I should get the idea to look one page back in the thread before posting...
That looks gigantic. How much of a performance hit would you take if you reduced these numbers? And what are the JVM defaults (when the arguments aren't set)?Reason I'm asking: my new 4 GHz Haswell quadcore, 16 GB RAM desktop just smiles mildly at those values even with both client and server running, it just has that much in reserves. However, the usage of JVM arguments to boost performance on such a system is limited in the first place, because performance is already very high.
On the other hand, older systems desperately need any bits of extra performance they can get. Sometimes I invite friends over for some local LAN play, and they generally show up with clunky old laptops that struggle to get good FPS. Your suggested JVM arguments won't work for them simply by virtue of not having that much memory to invest. Do you maybe have a recommendation on what to do on a computer with only small amounts of system memory installed? 2GB, 4GB? Heck, some people are limited to odd ~3GB by virtue of a 32bit operating system...
EDIT: Yeah, maybe I should get the idea to look one page back in the thread before posting...
JVM defaults depend a lot on OS and CPU brand actually, so it varies. Win7 amd64 codecache is default to 2GB, which is also the current maximum as far as i've been able to tell. Permsize has no default that I have found (that means IDK if there is a default, but i assume no at this point.) as far as lowering them for 64bit machines with only say, 4GB of ram, its been done. there is a performance loss, esp. in SSP, but not as bad in SMP. Simply cut all the numbers in half (1GB Xms/Xmx, 256m Xmn, 512m permsize, and 1GB of codecache.)
As far as 32bit, well, this setup is meant to be RAM intensive. there are a few things that i dont take into account in these that are default true in 64bit that are defaut false in 32bitm (compressedoops for example.) playing a modpack like Unleashed is troubling, to say the least, in SSP on a 32bit system let alone trying to optimize it. my JVMs barely keep SSP optimized as is on a 64bit system due to the client AND server running in one thread. (Shakes fist a Mojang.)
the one jvm i dont WANT to use, but was necessary to keep JIT from running in Interpreted mode only after about a half hour of play, is the CodeCacheFlushing. It forces JIT to scan through the codecache and drop as many compiled methods as possible to free space for new methods to be compiled. this is the part that causes the hit in SSP, but is usually not even noticeable on SMP since its not working on both server and client at the same time. This is also the reason the PermSize is so high, to prevent a horribly bad lag spike that occasionally happens if the JIT decides to decompile half or more of the codecache at once. although it has only happened to me a few times, it caused me to crash with OOM:permgen because the JVM was running a moment of heavy GC, chunkloading, rendering, my production line, etc. all at once and wasnt able to resize the permgen correctly. so i avoid the possibility of that randomly occuring by setting the permsize high.
all in all, i try to avoid interpreted mode for as many methods as i possibly can. interpreted mod is an average 9.5 (IIRC) times SLOWER than running in compiler mode. The codecache limit is the real factor in what keeps MC laggy (your CPU is actually second to that, remarkable) since you cant keep all 62GB of mods (the size of the unleashed server mods folder, not including forge, coremods, or minecraft.) force compiled in an environment like Java, since the compilation of methods and classes occurs in RAM instead of on disk.
edited to remove that irritating smiley in OOMermgen
As far as 32bit, well, this setup is meant to be RAM intensive. there are a few things that i dont take into account in these that are default true in 64bit that are defaut false in 32bitm (compressedoops for example.) playing a modpack like Unleashed is troubling, to say the least, in SSP on a 32bit system let alone trying to optimize it. my JVMs barely keep SSP optimized as is on a 64bit system due to the client AND server running in one thread. (Shakes fist a Mojang.)
the one jvm i dont WANT to use, but was necessary to keep JIT from running in Interpreted mode only after about a half hour of play, is the CodeCacheFlushing. It forces JIT to scan through the codecache and drop as many compiled methods as possible to free space for new methods to be compiled. this is the part that causes the hit in SSP, but is usually not even noticeable on SMP since its not working on both server and client at the same time. This is also the reason the PermSize is so high, to prevent a horribly bad lag spike that occasionally happens if the JIT decides to decompile half or more of the codecache at once. although it has only happened to me a few times, it caused me to crash with OOM:permgen because the JVM was running a moment of heavy GC, chunkloading, rendering, my production line, etc. all at once and wasnt able to resize the permgen correctly. so i avoid the possibility of that randomly occuring by setting the permsize high.
all in all, i try to avoid interpreted mode for as many methods as i possibly can. interpreted mod is an average 9.5 (IIRC) times SLOWER than running in compiler mode. The codecache limit is the real factor in what keeps MC laggy (your CPU is actually second to that, remarkable) since you cant keep all 62GB of mods (the size of the unleashed server mods folder, not including forge, coremods, or minecraft.) force compiled in an environment like Java, since the compilation of methods and classes occurs in RAM instead of on disk.
edited to remove that irritating smiley in OOM
ermgenInteresting info, thanks. I sort of feel vindicated now for making the packs I play with as small as possible (I don't run Unleashed as-is, for example, because a good 50% of the content is of no interest to me).
In my experience, large heap memory doesn't really feel all that important (I start my client with 2 GB but I've never seen it utilize even 1 of that), so in a memory limited environment preferring large codecaches and permgen space over heap memory might make sense?
In my experience, large heap memory doesn't really feel all that important (I start my client with 2 GB but I've never seen it utilize even 1 of that), so in a memory limited environment preferring large codecaches and permgen space over heap memory might make sense?
Yes. Though a PermSize of 128m normally suffices if your not trying to make the JVM attempt what I try to do in the OP. In most cases, setting a high Heap is actually counter intuitive performance wise. It just forces the GC to run harder and lag the main java thread. What really hits java, esp with MC is the backend. If, for example, somehow the main chunkloading methods are decompiled to interpreted mode, your performance drops dramatically even if the render methods stay compiled since the render methods take their information from what's chunkloaded and chunkupdated.
I was told (idr by who) that there is a way to force specific methods to always compile and stay compiled, but I haven't figured out how yet (or if there even is a way and I wasn't just led astray on that.)
I was told (idr by who) that there is a way to force specific methods to always compile and stay compiled, but I haven't figured out how yet (or if there even is a way and I wasn't just led astray on that.)
I'm not sure if you can control the JIT from within the Java code itself, and if you can, that would be bad for modders to do. imagine if a modder decided everything in his/her mod was important, FORCECOMPILE IT ALL! with a 3GB mod? granted its smaller compiled, but, no.
now if i can find a way to have an important method list for a MODPACK that can be read by the jvm to forcecompile the necessary class/methods for optimum running efficiency for that specific pack, i would a very happy person. (even if someone else figured it out, i would still be very very happy)
edit: that 3GB mod assumes absolutely nothing but code. no other resources included.
now if i can find a way to have an important method list for a MODPACK that can be read by the jvm to forcecompile the necessary class/methods for optimum running efficiency for that specific pack, i would a very happy person. (even if someone else figured it out, i would still be very very happy)
edit: that 3GB mod assumes absolutely nothing but code. no other resources included.
Fascinating stuff....
So how does one tell if the JIT compiler is running at any given time? And then how does one tell how much code cache is used/available? Are there benchmark tools you use to check this stuff?
It would be fun to see how much compiled code is actually USED in the course of running my server over a few days.
I use the same arguments for 1.4, 1.5, and 1.6. And yes, already tested on java 7u40 too
I use the same arguments for 1.4, 1.5, and 1.6. And yes, already tested on java 7u40 too
WOOT!
How's about for the vaniller launcher?
there is a spot for them in there under Edit Profile. Use the server arguments in the vanilla launcher.
I use the same arguments for 1.4, 1.5, and 1.6. And yes, already tested on java 7u40 too
Pretty Cool... Thanks!