Seeking answer to a GC pattern

[Thomas Schatzl]

Hi,


> On 10/26/2015 12:33 PM, Jun Zhuang wrote:
>         Hi,
>          
>         When running performance testing for a java web service
>         running on JBOSS, I observed a clear saw-tooth pattern in CPU
>         utilization that closely follows the GC cycles. see below: 
>         
  one issue that could cause this is nepotism
(http://www.memorymanagement.org/glossary/n.html) of the objects that
continously get promoted to the old gen, that is cyclically cleaned up
by a kind of full gc.

I.e. over time more and more actually dead objects get promoted to the
old gen, but due to how generational gc works, they keep more and more
objects in young gen alive.

That would also explain why the problem is the same for any gc.

The only real solution that you can do is make the application code null
out references. Or make sure by proper young gen sizing that such
pointers are not created, i.e. no objects that might keep alive many
others in the young gen get promoted. That latter is a very brittle
"solution" though.

It may also just be the application though. One hint whether this is the
fault of nepotism is take heap snapshots (e.g. jmap -histo:live <pid>
should do fine), and look if the amount of live data stays roughly the
same when taken at different times of that increase in heap memory (or
at least does not increase similarly to the graphs).

If it is not nepotism, using heap dumps and to some degree the histogram
you may get information on what is keeping stuff alive.

Then you know whether it the problem are really dead objects keeping
stuff alive in young gen or not.

Thanks,
  Thomas