| From | Sent On | Attachments |
|---|---|---|
| Donald Armstrong | Aug 11, 2010 9:14 am | |
| Christopher Schultz | Aug 11, 2010 10:33 am | |
| Donald Armstrong | Aug 11, 2010 5:05 pm | |
| Konstantin Kolinko | Aug 12, 2010 4:47 am | |
| Christopher Schultz | Aug 12, 2010 7:14 am | |
| Donald Armstrong | Aug 12, 2010 2:04 pm | |
| Christopher Schultz | Aug 13, 2010 1:02 pm | |
| dona...@gmail.com | Aug 13, 2010 1:39 pm |
| Subject: | Re: JreMemoryLeakPreventionListener and hourly Full GC | |
|---|---|---|
| From: | Donald Armstrong (dona...@gmail.com) | |
| Date: | Aug 11, 2010 5:05:44 pm | |
| List: | org.apache.tomcat.users | |
Thanks for your attention chris,
We've identified why every hour: sun.misc.GC.requestLatency(3600000l)
I was able to confirm with the tomcat documentation that with gcDaemonProtection enabled, the "GC Daemon" thread is running.
We've identified why the Full GC; I've looked at the decompiled code for the sun.misc.GC class and there is a System.gc() call buried in there. It is hard to read, but likely here the Full GC is happening.
{ synchronized(GC.lock) { l = GC.latencyTarget; if(l != 9223372036854775807L) break label0; GC.daemon = null; } return; } long l1 = GC.maxObjectInspectionAge(); if(l1 >= l) { System.gc(); l1 = 0L; }
The documentation does not indicate if the JreMemoryLeakPreventionListener should be enabled for production environments, but based on this information, probably not?
Thank you for your opinion.
Donnie
On Wed, Aug 11, 2010 at 12:34 PM, Christopher Schultz <chr...@christopherschultz.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Donald,
On 8/11/2010 12:15 PM, Donald Armstrong wrote:
We have recently deployed tomcat-6.0.28 in our organization and are noticing every hour, a Full GC is occurring. The same application, same JVM, same JVM args, just a new tomcat release.
I have addressed the issue by adjusting the server.xml and disabling gcDaemonProtection.
Why?
Ideas on what is causing the Full GC and why every hour?
There is no javadoc for this class which is unfortunate, but the documentation in http://tomcat.apache.org/tomcat-6.0-doc/config/listeners.html is likely where you found this configuration option.
Here's what it says about gcDaemonProtection:
" Enables protection so that calls to sun.misc.GC.requestLatency(long) triggered by a web application do not result in a memory leak. Use of RMI is likely to trigger a call to this method. A side effect of enabling this protection is the creation of a thread named "GC Daemon". The protection is uses reflection to access internal Sun classes and may generate errors on startup on non-Sun JVMs. The default is true. "
Looking at the code for JreMemoryLeakPreventionListener, no threads are fired from that code. The code in there calls the static method sun.misc.GC.requestLatency(3600000l) - that's one hour, if the argument is in ms. I'm having trouble following the decompiled code, but I can't find anywhere that a Thread is actually started.
Have you tried to take a thread dump to see what threads are running? Presumably, you ought to see something interesting in there. Are you able to run a profiler against the process to see where the thread is created?
- -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxi3w4ACgkQ9CaO5/Lv0PAYBQCfe7+POwLPcW6p9QQyWlLbSspZ Z+EAn1H1FrU2QQ40fUiywug7Ohz2fpP7 =GC7n -----END PGP SIGNATURE-----





