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.
Created attachment 28810 [details] Docs patch for JreMemoryLeakPreventionListener.
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
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.
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.
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.
(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.
Is this bug fix going to be backported to Tomcat 6.x?
I proposed backport of r1343895 for 6.0.
Fixed in 6.0 in r1347072 and will be in 6.0.36.
Configurable value added in r1377543
(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