tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 51195] "Find leaks" reports a false positive memory/classloader leak
Date Tue, 24 May 2011 13:59:07 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=51195

--- Comment #7 from Christopher Schultz <chris@christopherschultz.net> 2011-05-24 13:59:07
UTC ---
Joern,
(In reply to comment #6)
> The cleanup performed in the code is merely to prevent a *false* memory leak
> warning. A real leak does, in fact, not exist. This is the reason why I put it
> directly before the execution of System.gc() in the "Find Leaks" function.

One could argue that a memory leak does, in fact, exist: just because the
references will be /eventually/ collected doesn't mean that they won't loiter
for quite a long time... unless the GC is getting seriously low on memory,
those objects will stick in memory, and so, likely, will the WebappClassLoader,
and all of the java.lang.Class objects it manages.

I agree with Mark that this feature is best placed into WebappClassLoader and
run during it's disposal sequence.

> Since "Find Leaks" isn't supposed to be executed in a production environment, I
> don't think that any further optimization (suggestion in 2.) makes sense.

If this will be used in WebappClassLoader, such optimizations should obviously
be made.

> It
> would probably make sense if this code would indeed be added to the normal
> undeploy procedure but I really don't think that this is necessary or
> advisable.

This could be implemented as a utility method accessible to both pieces of
code, and called directly during a "find leaks" operation... I would have to
look at the "find leaks" feature to see if that would even be necessary... my
sense is that the WCL is disposed before the leaks are detected, so I don't
think any changes to the manager app would need to be made.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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


Mime
View raw message