|Summary:||The JreMemoryLeakPreventionListener causes a full GC every hour when gcDaemonProtection=true|
|Product:||Tomcat 7||Reporter:||Pid <bugzilla>|
|Component:||Catalina||Assignee:||Tomcat Developers Mailing List <dev>|
Increases timeout on sun.misc.GC.requestLatency in JreMemoryLeakPreventionListener
Docs patch for JreMemoryLeakPreventionListener.
Description Pid 2012-05-21 14:41:43 UTC
Created attachment 28809 [details] Increases timeout on sun.misc.GC.requestLatency in JreMemoryLeakPreventionListener The JreMemoryLeakPreventionListener causes a full GC every hour when gcDaemonProtection=true. The prevention technique invokes sun.misc.GC.requestLatency with a value of 360000. Increasing the value to Long.MAX_VALUE would be beneficial. The attached patches add a default setting of Long.MAX_VALUE (add documentation update), but also permit it to be configured to a lower value using a System property.
Comment 1 Pid 2012-05-21 14:42:11 UTC
Created attachment 28810 [details] Docs patch for JreMemoryLeakPreventionListener.
Comment 2 Konstantin Kolinko 2012-05-25 07:04:26 UTC
For reference, a thread on users list about observing this issue with 6.0.28, "JreMemoryLeakPreventionListener and hourly Full GC" (2010-08): http://marc.info/?t=128156139600002&r=1&w=2 http://markmail.org/thread/53rxdqyqnjhlzk6d
Comment 3 Konstantin Kolinko 2012-05-25 07:32:10 UTC
As far as I can see, Long.MAX_VALUE in s.m.GC is treated specially, and I suspect that using this specific value may break the memory leak prevention feature. I am OK with making the latency configurable, though I think it is better to just add a property on this listener class, instead of a system property.
Comment 4 Mark Thomas 2012-05-29 13:40:08 UTC
Moving this to bug status rather than enhancement. I need to review the JVM code again but I suspect using Long.MAX_VALUE-1 would achieve what was originally intended.
Comment 5 Mark Thomas 2012-05-29 18:30:16 UTC
Fixed in trunk and 7.0.x and will be included in 7.0.28. By default, a full GC will now occur roughly every 290 million years.
Comment 6 Christopher Schultz 2012-05-29 20:44:45 UTC
(In reply to comment #5) > Fixed in trunk and 7.0.x and will be included in 7.0.28. By default, a full > GC will now occur roughly every 290 million years. Then it's probably going to be a big one.
Comment 7 fglez.tsl 2012-05-30 07:26:16 UTC
Is this bug fix going to be backported to Tomcat 6.x?
Comment 9 Konstantin Kolinko 2012-06-06 19:40:53 UTC
Fixed in 6.0 in r1347072 and will be in 6.0.36.
Comment 11 Konstantin Kolinko 2012-08-29 23:33:06 UTC
(In reply to comment #10) > Configurable value added in r1377543 Reverted in r1378132, based on "Re: svn commit: r1377689" discussion on dev@, http://tomcat.markmail.org/thread/6hmjgrzys5txekew