If you are using CMFX and trying to "tune" the JVM - or maybe even just adding a class path, I have some advice for you. Don't use the CF Administrator to do it! Instead, get used to editing the jvm.config file located in cfusionmx7/runtime/bin. Not only will you benefit from gaining a better knowledge of the inner workings of your JVM, but you will also miss out on a ticklish bug that will have you scratching your head in frustration. Here's the scoop.

To start, here is the "default" java.args string from the jvm.config file.

This is the default "setting" that is used when you install Coldfusion MX. I may have adjusted the -Xmx512m variable, but everything else is the same I believe. Now, the default settings are designed to handle the maximum number of server configurations. In other words they are designed like a pickup truck, not a sports car. Macromedia wants to make sure that the maximum number of folks possible end up with a server that works reasonably well after a default install of the server - makes sense right?

Please note - just because it does work doesn't mean you should not be making adjustments to it that make sense for your server. There are a great many things to adjust that can make your server run better (or worse). One of those things is called "Garbage Collection" (GC). GC is how the JVM handles recovering memory that is no longer referenced by any object. It's how the JVM "self-tunes" the amount of memory it needs and uses. Here's the deal, there are actually several kinds of GC you can use. MM has set the JVM to use a type of GC called Parallel GC. It's the argument switch that says -XX:+UseParallelGC. According to Java Guru Robi Sen, this switch is not as effective as -XX:+UseConcMarkSweepGC.

So naturally, you might add this line to your JVM args. Here's the args from my blog server:

If you do this you should no longer edit the JVM settings from the Coldfusion Administrator. Why? Because you have removed the default garbage collector and installed one that the CF Admin is not smart enough to recognize. When it goes to write your new config file it's going to say to itself "self... you don't have a Garbage collector in your arguments! You better add one right away!". It will then proceed to add the -XX:+UseParallelGC line to the arguments.

When you restart the server it will fail because the JVM will not be able to determine which GC to use (since both will be specified). You will have to go looking in the *server*-err.log files in the /runtime/logs/ directory to figure it out. I've been able to duplicate this about 3 times (2 times quite by accident or neglect). It may have something to do with the order of my arguments. Someone may be able to shed some light on it for me. But until I see otherwise, I'm editing the jvm.config file manually.

at one point the jrun administrator (JMC) would move the -server arg to a different order and then the jvm would fail to start. So yeah, jvm.config is a better bet. It's good to up the perm size, been bit by that before. I actually usually set jvms with equal Xms and Xmx of 1024m on 32 Bit Windows... wish I ran solaris and could do things like -Xmx8000m

While I do the -Xms and -Xmx as the same size, it's worth noting that there can be problems when you set these values to be the same high value (i.e., 1024). Apparently, on some systems, the JVM can have a problem trying to reserve that much space all at once. That being said, I've not run into that on our Solaris boxes, but it should be kept in mind.

The jvm won't allocate a gig all at once, the -Xms setting just means it will never give any back to the OS (it's a "minimum", not an "initial" as some believe). I haven't experienced any issues with those memory settings (provided there is ample RAM left over for the OS). That's pretty much as high as you want on a 32-bit OS + 1.4 jvm, though. There have been many reports of instability past 1.5gb on 32-bit jvms. I envy my colleagues on 64-bit solaris + 5.0 jvms though!

The reason you set them equal is to avoid heap fragmentation as well as long pauses as the JVM allocates more memory. There are other settings you can set the same as well such as the size of the perm gen. As with everything else you should test these settings underload to make sure they help. Randomly changing settings based on one person's experiance or someone elses application is a bad idea.