JVM Options

-Xms (minimum heap size) should match the maximum heap size value. Since the JVM begins by allocating the minimum heap size and grow from there, it spends time requesting memory from the system once it crosses the minimum memory boundary. Setting both the maximum and minimum heap sizes to the same value allows the JVM to allocate the maximum amount up front and not request any more from the system. This also shields the JVM from other processes in the system taking all the available memory and starving the JVM.

-Xmx is the maximum heap size. Since a large number of objects can be temporarily cached by the server, this parameter should not be left at its default size (64M). A value of 256M is recommended even for the smallest installations. As a rule, if there are hundreds of users, this value should be doubled, and tripled if there are thousands. This setting is platform-dependent, but should never exceed 1.5G. For more information about determining the value of -Xmx, see Calculating Maximum Heap Size (-Xmx JVM option).

-Xss sets the maximum stack size to be used by threads. Every thread that is spawned during the execution of the program passed to Java has this value as its stack size. Therefore, this setting sets the stack size of threads running in the Live Collaboration server. If this option is omitted, the JVM selects values for some operating systems and for others it uses the operating system's default thread size. This system value is different depending on the operating system used (i.e. on Windows 2000 it's 1M, but on some Unix versions it can be as low as 64K). It's important to use this option to guarantee that the Live Collaboration server has enough stack space to function correctly.

For Sun Java System Application Server, increase the StackSize setting in /var/opt/SUNWappservere7/domains/domain1/server1/config/init.conf to at least 512 KB, particularly if you are running RMI in process (RIP). Refer to Sun documentation for tuning recommendations. The default setting is 130 KB, which is not large enough, and if not set correctly, causes certain operations in ENOVIA products to fail.

This setting governs the size of the eden memory pool allocated (i.e., the amount of memory allocated for new objects versus the amount of memory allocated for keeping older objects). This should be calculated as between .45 to .50 of the maximum heap size value. Newer objects are transferred by the JVM's "garbage collection" system to the older pool. Keeping the NewSize relatively high (compared to the maximum heap size) benefits ENOVIA Live Collaboration processing because ENOVIA Live Collaboration objects are not expected to persist for a long time-most not long enough to be transferred to the old pool.

This is set to the same size as the NewSize to save time allocating more memory for the eden pool.

This option prevents Java code executing within the Java process from forcing garbage collections by calling, for example, system.gc().

This setting is no longer checked by the configuration checker. In general, explicit garbage collection should be enabled; that is, this setting should not be used.

Use of this setting has been found to delay fullGC from occurring and thus remote objects with c++ references might be kept active longer than necessary.

This is the ratio of the eden space (the memory pool allocated for newer objects that have been created) versus the pool for older objects. The Sun JVM default is 25, but ENOVIA recommends a value of 2 since most objects have a short lifespan.

This setting is the amount of memory set aside for loading all necessary classes that are needed by an application. This setting may need adjustments, particularly in a WebLogic 7/RMI RIP configuration. Refer to the "Installing a WebLogic Server" topic in Live Collaboration - Server Installation Help.

-XX settings are for use only with Sun's JVM.