You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2016/05/19 11:21:08 UTC

[PROPOSAL] Remove StandardContext.clearReferencesStatic in 9.0.x

As you are probably aware, I have been working through the memory leak
protection / detection code checking that the code is still relevant for
Tomcat 9. Having reviewed the history of clearReferencesStatic I'd like
to propose removing it in 9.0.x and deprecating it in 8.0.x.

clearReferencesStatic was originally added to address unidentified
memory leaks including suspected GC bugs in early JDKs (1.3, 1.4 time
frame). It is disabled by default because it is known to break some
libraries such as log4j. My reasons for proposing removal are:

1. The presence of GC bugs was just a theory. My own theory is that
   the suspected GC bugs were actually memory leaks where the root
   cause had not been identified.

2. In the unlikely event some issues do remain, I'd prefer to identify
   the root causes and work-around them rather than apply this general
   fix which is as likely, if not more likely, to break things.

3. Disabling this by default has not caused an increase in the reports
   of memory leaks.

Thoughts? Objections?

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Re: [PROPOSAL] Remove StandardContext.clearReferencesStatic in 9.0.x

Posted by Rémy Maucherat <re...@apache.org>.
2016-05-19 13:21 GMT+02:00 Mark Thomas <ma...@apache.org>:

> As you are probably aware, I have been working through the memory leak
> protection / detection code checking that the code is still relevant for
> Tomcat 9. Having reviewed the history of clearReferencesStatic I'd like
> to propose removing it in 9.0.x and deprecating it in 8.0.x.
>

+1

>
> clearReferencesStatic was originally added to address unidentified
> memory leaks including suspected GC bugs in early JDKs (1.3, 1.4 time
> frame). It is disabled by default because it is known to break some
> libraries such as log4j. My reasons for proposing removal are:
>
> 1. The presence of GC bugs was just a theory. My own theory is that
>    the suspected GC bugs were actually memory leaks where the root
>    cause had not been identified.
>
> 2. In the unlikely event some issues do remain, I'd prefer to identify
>    the root causes and work-around them rather than apply this general
>    fix which is as likely, if not more likely, to break things.
>
> 3. Disabling this by default has not caused an increase in the reports
>    of memory leaks.
>
> Thoughts? Objections?
>
> No problem, that's pretty much its history.

Rémy

Re: [PROPOSAL] Remove StandardContext.clearReferencesStatic in 9.0.x

Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,

On 5/19/16 7:21 AM, Mark Thomas wrote:
> As you are probably aware, I have been working through the memory leak
> protection / detection code checking that the code is still relevant for
> Tomcat 9. Having reviewed the history of clearReferencesStatic I'd like
> to propose removing it in 9.0.x and deprecating it in 8.0.x.
> 
> clearReferencesStatic was originally added to address unidentified
> memory leaks including suspected GC bugs in early JDKs (1.3, 1.4 time
> frame). It is disabled by default because it is known to break some
> libraries such as log4j. My reasons for proposing removal are:
> 
> 1. The presence of GC bugs was just a theory. My own theory is that
>    the suspected GC bugs were actually memory leaks where the root
>    cause had not been identified.
> 
> 2. In the unlikely event some issues do remain, I'd prefer to identify
>    the root causes and work-around them rather than apply this general
>    fix which is as likely, if not more likely, to break things.
> 
> 3. Disabling this by default has not caused an increase in the reports
>    of memory leaks.
> 
> Thoughts? Objections?

+1 to remove.

Might want to deprecate in Tomcat 8.5, leave it alone in Tomcat 8? I
suppose deprecating a method really changes nothing, so I have no
objections to back-porting that deprecation as far as you'd care to.

-chris