|
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:
- In the Administrative Console, expand Servers.
- Select Application Servers > your Application Server .
- In the Additional Properties section, select Process Definition >
Java Virtual Machine > Generic JVM arguments.
Adding a JVM argument in WebSphere Application Server V6.0
- In the Administrative Console, expand Servers.
- Select Application Servers > your Application Server .
- On the Configuration tab, under Server Infrastructure, expand Java and
Process Management, and click Process Definition.
- Under the Additional Properties section, click Java Virtual
Machine.
- In the Generic JVM arguments.
Adding a JVM argument in WebSphere Application Server V6.1
- In the Administrative Console, click Servers > Application Servers
> server.
- Under Server Infrastructure, click Java and Process Management >
Process Definition > Java Virtual Machine.
- 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. |
|
|
|