On 24.02.2010 11:47, Mark Thomas wrote:
On 24/02/2010 10:18, Rainer Jung wrote:
On 24.02.2010 01:07, ma...@apache.org wrote:
Author: markt
Date: Wed Feb 24 00:07:06 2010
New Revision: 915603

URL: http://svn.apache.org/viewvc?rev=915603&view=rev
Log:
Add basic memory leak detection for JMX and manager (kkolinko/markt)

Should we add a note, that the feature will not work in case System.gc()
has been disabled, e.g. by setting -XX:+DisableExplicitGC on the command
line (Sun VM)?

More documentation is always good. There is, of course, no guarantee
that the GC will run anyway.

OK, I'll have a look if noone beats me to it.

I think there's no good way yet to determine whether explicit GCs are
possible or not. One could check the input arguments provided by the
runtime platform mbean, but I think it's not worth it.

I don't have the details (vendor, versions etc) to hand but you can get
counts of GC via JMX. It may be viable - depending on which vendors/jvms
support it - to check the GC count before and after we try to trigger it.

Good point. It's

java.lang.management.GarbageCollectorMXBean.getCollectionCount()

which is in java.lang.management and not only in sun.com.management.

Problem is, that even for Sun VM it's not trivial to find the right one. In general, there are at least two of those, one for the young generation (minor GC), and the other one for tenured, perm and young (major GC). One could use the name of the bean, or the names of the memory pools it handles. But as we know there are various possible implementations using bean names containing "MarkSweepCompact", "PS MarkSweep", "ConcurrentMarkSweep" and memory pool names containing "Tenured Gen", "PS Old Gen", "CMS Old Gen". Then the there's G1 and I didn't have a look how the names are in that case. So all in all I see no robust way to find the right GarbageCollectorMXBean.

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to