Details
Major Description
After looking into why our application GC tuning wasn't working/taking any effect and full gc continued to occur every hour, and saw from the GC logs that System.GC was being called, traced it down to our use of CXF framework, where we are using it for HTTP WS-SOAP Service calls.
Seems that the following is being set code-ally by the JDKBugHacks, looking through the code history seems this got added on the 28th Feb 2011.
From the comments it seems this has been added due to RMI. Not 100% sure why you're wanting to codally override RMI setting this up (especially as in jdk 6 + it by default is the same value 1 hour) and it is well documented for developers who want to tweek their application (especially if they're on earlier java versions) with regards to GC how to change this setting using the following two jvm switches to change the interval anyhow.
-Dsun.rmi.dgc.server.gcInterval
-Dsun.rmi.dgc.client.gcInterval
And can actually turn off completely by setting it to 0x7ffffffffffffffe but that is by the by.
The issues i have is that as a user of the framework,
a) i am unable to turn off the hard coding by any feature flag, and this affects my gc turning of my application.
b) If a user is using CXF with no RMI why set this up? Only setup if using RMI if it is really need so that it doesnt effect users of the framework using it for http service calls.
I take it that these "hacks" are influenced heavily from tomcat, but this is because of its servlet hot deployable class loading features. Even so for that tomcat do allow two options to disable this feature if you wish, i.e. u don't want hot deploy to tomcat thus not worried about this leak prevention with the class loader and you want to fine tune your applications gc for the applications requirements and SLA. They provide the following nice features:
Configure to not add the gcDaemonProtection
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" gcDaemonProtection="false"/>
And the ability to Disable the listener altogether
Code in question in the JDKBugHacks class.
// Several components end up calling:
// sun.misc.GC.requestLatency(long)
//
// Those libraries / components known to trigger memory leaks due to
// eventual calls to requestLatency(long) are:
// - javax.management.remote.rmi.RMIConnectorServer.start()
try {
Class<?> clazz = Class.forName("sun.misc.GC");
Method method = clazz.getDeclaredMethod("requestLatency",
new Class[]
);
method.invoke(null, Long.valueOf(3600000));
} catch (Throwable e)