Bug 53267 - The JreMemoryLeakPreventionListener causes a full GC every hour when gcDaemonProtection=true
Summary: The JreMemoryLeakPreventionListener causes a full GC every hour when gcDaemon...
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Catalina (show other bugs)
Version: trunk
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-21 14:41 UTC by Pid
Modified: 2014-02-17 13:48 UTC (History)
2 users (show)



Attachments
Increases timeout on sun.misc.GC.requestLatency in JreMemoryLeakPreventionListener (827 bytes, patch)
2012-05-21 14:41 UTC, Pid
Details | Diff
Docs patch for JreMemoryLeakPreventionListener. (657 bytes, patch)
2012-05-21 14:42 UTC, Pid
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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 8 Konstantin Kolinko 2012-05-31 13:26:05 UTC
I proposed backport of r1343895 for 6.0.
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 10 Filip Hanik 2012-08-26 23:45:05 UTC
Configurable value added in r1377543
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