Any Java programmer who ever went deeper into the details first has been confronted with the options to manipulate the heap size for the Java environment - the legendary space where all those objects reside. If you want to know about those options, you get an explanation by issuing the Java command with: Java -X
In the resulting list are the most important ones: the -Xms and the -Xmx options to set the initial and the maximum heap size. Because Web AS Java since 6.40 is started under the control of the startsap executable, you are not able to use those options directly. But, when starting the config tool from the server directory (something like C:\usr\sap\J2E\JC00\j2ee\configtool\configtool.bat), you will find them again. Yes, they are in the server settings. Along with with a couple of others you might never have seen. After starting the testing tool, click on "instance" and switch to "Server General" tab. Be sure to make changes only there, as changes on specific servers do not make any sense.
In the resulting list are the most important ones: the -Xms and the -Xmx options to set the initial and the maximum heap size. Because Web AS Java since 6.40 is started under the control of the startsap executable, you are not able to use those options directly. But, when starting the config tool from the server directory (something like C:\usr\sap\J2E\JC00\j2ee\configtool\configtool.bat), you will find them again. Yes, they are in the server settings. Along with with a couple of others you might never have seen. After starting the testing tool, click on "instance" and switch to "Server General" tab. Be sure to make changes only there, as changes on specific servers do not make any sense.
A technological intro
As I said before, the two values for setting the heap of the Java VM are set here. Additonally, there are some other options to influence heap. To understand them we have to discuss how the heap works. Just to recall: the heap contains the Java objects that are initiated by the programs running. Objects that are released are wiped out by the garbage collector process on a regular basis. And here the trouble starts.
With current environments, your memory is usually quite large, and this results in the garbage collector (gc) being an expensive process. We have to chose between two extremes: running the gc all the time to be sure to always find all released objects and delete them, or nearly never run gc, thereby growing the objects into the heap. Obviously, both alternatives have significant drawbacks. The first one hits performance delicately, while the second one takes on the risk of finally running into out-of-memory errors, that the whole Java world once was built to keep us safe of....
Nits and bits
First of all, there is the value for permSize. This is a piece of memory outside the heap that contains Java classes (to those who had their Java course a while ago: remember the classes are what you have written, and they describe the objects that will run and be stored in heap). I think we all can guess what happens if this is too small: your computer starts swapping - the most genius idea to enhance memory that at the same time has the biggest slow-down effect.
The value you can set for permSize is -XX:MaxPermSize. My sources say that it's a must to set this value to a minimum of 192 MB. (A glance on my screen shot tells you that my machine doesn't have this. So that's why...).
Let's get back to the heap. Obviously, we need a more intelligent strategy to keep our space clean. And that strategy is what those other -X options are involved with.
To avoid too much gc activity the idea is to check whether we really have to go through the complete heap all of the time. By checking heap activity, some smart people found out that there is a lot of short living, and at the same time quite small objects exist in a usual Java environment. That brought up the idea to section part of the heap into what we want to call the style="font-weight: bold;">newSize space. First of all, this is the part of the heap where all new objects are created. Since this space is much smaller then general heap, a gc run is also much more effective in there. Objects like iteration variables will be built in here and deleted in a second (in much less then a second most of the time, I guess).
Found the problem already? How do we decide which objects are to be written into normal heap? The first step is to put them into a part of the newSize area called a survivor space. There are two of those survivor spaces which are used alternately. Once an object grows to a certain 'age', it then gets copied into normal heap. Details about this system are in the document linked at the beginning of this article.
Oh yes, and additional useful information: This is how Sun's VMs work. Other VMs may work slightly differently. As Sun's VM is also the one that runs under Windows, this is at least relevant for everybody currently developing Java for SAP NetWeaver.
Special thanks go to Daniel Stollenwerk who made the garbage collector picture and Dirk Marwinski for all the tips on GC.
