Websphere Garbage Collection : How it's done

This morning I noticed one of my JVM (managed Node) log file native_stderr.log was over grown to 4GB. “tail -f native_stderr.log” was scrolling pages continuously indicating some issue with JVM garbage collection.

In Web applications, memory utilization can impact system performance significantly. One of the most common memory problems is memory leak, which causes severe performance degradation. In theory, memory leaks should not happen in Java™ because it has Garbage Collection (GC). However, GC only cleans up unused objects that are not referenced anymore. Therefore, if an object is not used, but is still referenced, GC does not remove it, which leads to memory leaks. Beside memory leaks, other memory problems that you might encounter are memory fragmentation, large objects, and tuning problems. In many cases, these memory problems can cause the application server to crash. Many users first notice that application server performance gradually declines, and eventually crashes with OutOfMemory exceptions.

<af type=”nursery” id=”5465″ timestamp=”Aug 12 12:42:37 2010″ intervalms=”190.797″>
* type:
* id: The id represents how many times the gc was executed
* intervalms: The time in ms since last time gc was executed
* timestamp: time of gc

<minimum requested_bytes=”168″ />
The minimum represents the number of bytes that were requested and JVM couldnot allocate them so it had to trigger garbage collection cycle.

The af element has 3 main child elements first tenured element has data about the tenured memory position before gc then gc element represents data about what happened during gc, such as time spent in mark, sweep and compact phases, The second tenured element represents the position of tenured memory after gc.
The IBM Support assistance has IBM Pattern modeling and Analysis tool for Java Garbage collection tool that can be used to analyze the garbage collection.