Preventing mark stack overflows during garbage collection in the Java SDK
 Technote (troubleshooting)
 
Problem(Abstract)
In the Java™ SDK shipped for AIX®, Linux® and Windows®, the mark stack is created during the first phase of garbage collection when live objects are marked for retention. Objects are taken off the stack and any references held by the object are added. Mark stack overflow in itself does not indicate an error condition, but it does result in increased CPU utilization.
 
Cause
Mark stack overflow can be caused by a Java maximum heap size that is set too high.
 
Resolving the problem
There is no way to totally avoid a mark stack overflow if you have deep, wide object trees.

The best way to reduce mark stack overflows is to reduce the Java maximum heap size. Any mark stack overflow results in a scan of the entire Java heap, which is expensive in terms of CPU utilization. So, if heap is not occupied to the full extent, the recommendation is to reduce the Xmx to eliminate or minimize mark stack overflow.

Additionally, adding the following Java Virtual Machine (JVM™) argument helps address mark stack overflows:
-Xgcpolicy:optavgpause

This reduces and makes pause times more consistent when the heap occupancy rises. However, it also reduces throughput by approximately 5% depending on the application.
Increasing the number of CPUs on a system also helps address mark stack overflows by taking advantage of parallel garbage collection through gc helper threads. On a system with n processors, the default setting for -Xgcthreads is n - 1 when in resettable mode and n when not in resettable mode. This option sets the number of helper threads that the Garbage Collector uses for concurrent operations. On single CPU systems, no helper threads run. As the argument -Xgcthreads is set by default, no alterations are required with this parameter. No advantage is gained by increasing the number of helper threads above the default setting and IBM® support strongly recommends not to do this. Reducing or disabling helper threads prevents concurrent operations at the cost of performance, and might expose problems in this area.

Adding a JVM argument in WebSphere® Application Server V5.0 and V5.1:
  1. In the Administrative Console, expand Servers.
  2. Select Application Servers > your Application Server .
  3. In the Additional Properties section, select Process Definition > Java Virtual Machine > Generic JVM arguments.

Adding a JVM argument in WebSphere Application Server V6.0
  1. In the Administrative Console, expand Servers.
  2. Select Application Servers > your Application Server .
  3. On the Configuration tab, under Server Infrastructure, expand Java and Process Management, and click Process Definition.
  4. Under the Additional Properties section, click Java Virtual Machine.
  5. In the Generic JVM arguments.

Adding a JVM argument in WebSphere Application Server V6.1
  1. In the Administrative Console, click Servers > Application Servers > server.
  2. Under Server Infrastructure, click Java and Process Management > Process Definition > Java Virtual Machine.
  3. In the Generic JVM arguments field.

After making changes, save your changes to the master configuration, stop and restart the application server.

For more information on mark stack overflows, refer to the IBM Developer Kit and Runtime Environment Java 2 Technology Edition Diagnostics Guide.
 
Related information
IBM Developer Kit Diagnostics Guide
 
 
Cross Reference information
Segment Product Component Platform Version Edition
Application Servers Runtimes for Java Technology Java SDK
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Out of Memory
Operating system(s): Windows
Software version: 6.1
Software edition:
Reference #: 1164724
IBM Group: Software Group
Modified date: Oct 21, 2005