Frequently asked questions about the Garbage Collector

What are default values for the native stack (-Xss) and Java stack (-Xoss)? The Native stack size is machine-dependent, because it is based on the platform's C stack usage. The Java stack size is 400*1024 What is the difference between the GC policies optavgpause and optthruput? optthruput disables concurrent mark. If you do not have pause time problems (indicated by erratic application response times), you should get the best throughput with this option.

optavgpause enables concurrent mark. If you have problems with erratic application response times in garbage collection, you can alleviate them at the cost of some throughput when running with this option.

What is the default GC mode (optavgpause or optthruput)? optthruput - that is, concurrent marking is off. How many GC helper threads are spawned? What is their work? A platform. with n processors will have n-1 helper threads. These threads work along with the main GC thread during:

• Parallel mark phase
• Parallel bitwise sweep phase

You can control the number of GC helper threads with the -Xgcthreads option. Passing the -Xgcthreads1 option to Java results in no helper threads at all.

You gain little by setting -Xgcthreads to more than n-1 other than possibly alleviating mark-stack overflows, if you suffer from them.

Is incremental compaction enabled by default? Yes. But incremental compaction works only if the size of the heap is at least 128 MB. What is double allocation failure? Double allocation failure refers to the condition in which the GC believes that it has freed enough heap storage to satisfy the current allocation request, but still the allocation request fails. This is clearly an error condition, and it results in the JVM closing down with a "panic" error message. What are pinned and dosed objects? Pinned and dosed objects are the immovable objects on the Java heap. GC does not move these objects during compaction. These are the major cause of heap fragmentation.

All objects that are referenced from JNI are pinned. All objects on the heap that are referenced from the thread stacks are dosed.

How can I prevent Java heap fragmentation? Note that the following suggestions might not help avoid fragmentation in all cases.

• Start with a small heap. Set -Xms far lower than -Xmx. It might be appropriate to allow -Xms to default, because the default is a low value.
• Increase the maximum heap size, -Xmx.
• If the application uses JNI, make sure JNI references are properly cleared. All objects being referenced by JNI are pinned and not moved during compaction, contributing significantly to heap fragmentation.

Does running with -Xpartialcompactgc avoid heap fragmentation? This option can be useful when used with incremental compaction and will reduce fragmentation. However, it is no more effective than regular compaction for pinned and dosed objects. What is Mark Stack Overflow? Why is MSO bad for performance? Mark stacks are used for tracing all object reference chains from the roots. Each such reference that is found is pushed onto the mark stack so that it can be traced later. Mark stacks are of fixed size, so they can overflow. This situation is called Mark Stack Overflow (MSO). The algorithms to handle this situation are very expensive in processing terms, and so MSO is a big hit on GC performance. How can I prevent Mark Stack Overflow? There is nothing an application can do to avoid MSO, except to reduce the number of objects it allocates. The following suggestions are not guaranteed to avoid MSO:

• Increase the number of GC helper threads using -Xgcthreads command-line option
• Decrease the size of the Java heap using the -Xmx setting.
• Use a small initial value for the heap or use the default.

When and why does the Java heap expand? The JVM starts with a small default Java heap, and it expands the heap based on an application's allocation requests until it reaches the value specified by -Xmx. Expansion occurs after GC if GC is unable to free enough heap storage for an allocation request, or if the JVM determines that expanding the heap is required for better performance. When does the Java heap shrink? Heap shrinkage occurs when GC determines that there is a lot of free heap storage, and releasing some heap memory is beneficial for system performance. Heap shrinkage occurs after GC, but when all the threads are still suspended. Does the IBM® GC guarantee that it will clear all the unreachable objects? The IBM GC guarantees only that all the objects that were not reachable at the beginning of the mark phase will be collected. While running concurrently, our GC guarantees only that all the objects that were unreachable when concurrent mark began will be collected. Some objects might become unreachable during concurrent mark, but they are not guaranteed to be collected. I am getting an OutOfMemoryError. Does this mean that the Java heap is exhausted? Not necessarily. Sometimes the Java heap has free space but an OutOfMemoryError can occur. The error could occur because of

• Shortage of memory for other operations of the JVM.
• Some other memory allocation failing. The JVM throws an OutOfMemoryError in such situations.
• Excessive memory allocation in other parts of the application, unrelated to the JVM, if the JVM is just a part of the process, rather than the entire process (JVM through JNI, for instance).

How can I confirm if the OutOfMemoryError was caused by the Java heap becoming exhausted? Run with the -verbosegc option. VerboseGC will show messages such as Insufficient heap space to satisfy allocation request when the Java heap is exhausted When I see an OutOfMemoryError, does that mean that the Java program will exit? Not always. Java programs can catch the exception thrown when OutOfMemory occurs, and (possibly after freeing up some of the allocated objects) continue to run. What does verifyHeap do? What can we learn about the problem or crash from verifyHeap? The verifyHeap option can verify the integrity of the heap and free list during the phase of GC when all application threads are locked. It can be invoked with the -Dibm.dg.trc.print=st_verify_heap command-line option. It verifies the heap before the sweep phase and at the end of GC. verifyHeap walks the heap from the bottom to the top, until any of the following conditions occurs, or it reaches the end of the heap:

• The length of a chunk of memory is zero or too big to fit onto the heap.
• If the alloc bit is set (reachable object) and its method table or class block is NULL or invalid.
• If verifyHeap shows a problem before GC, that usually means that the problem was created by allocation routines or something outside the GC. If verifyHeap after GC shows a problem, while the verifyHeap before that GC has not shown any problems, it is likely that the problem has been created by GC.

How do I figure out if the Java heap is fragmented? When you see (from verboseGC) that the Java heap has a lot of free space, but the allocation request still fails, it usually points to a fragmented heap. To confirm this, run with -Dibm.dg.trc.print=st_verify. This option gives the number of pinned and dosed objects, a high number of which indicates a fragmented heap. Running with -Dibm.dg.trc.print=st_compact_verbose lists the pinned and dosed objects. In verboseGC output, sometimes I see more than one GC for one allocation failure. Why? You see this when GC decides to clear all soft references. gc0() is called once to do the regular garbage collection, and might run again one or two times to clear soft references. So you might see more than one GC cycle for one allocation failure.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/27378/viewspace-582493/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/27378/viewspace-582493/