Mattias Jiderhamn wrote (2009-12-11 08:34):
I should mention though, that there is still a minimum of two
EnvironmentClassLoaders for the given application after reloading at
least once. The former one seem to stick around somehow. We have
discussed this before, Scott; how references are kept inside
com.caucho.server.dispatch.Invocation, at least in a low traffic (dev /
debugging) environment.
On a web-app change the Invocation cache is cleared, so there shouldn't
be any old references there.
Could you please double check that? For example, what happens to the
503:ed requests received during redeployment?
I have an examplifying YourKit (freely available EAP) snapshot I could
send you if it helps.
Here is what I'm getting, which seems repeatable over and over in my
environment:
Startup: 9k loaded classes, no unloaded classes, 49 MB PermGen
First redeployment: 15k loaded classes, no unloaded classes, 77 MB
PermGen = one extra instance of the app with 6k classes loaded.
Assumed a total of 2 classloaders
Second redeployment: 15k loaded classes, 6k unloaded classes, 77 MB
PermGen = initial/first(?) instance GC:ed and a new one loaded. Still
2 classloaders.
Third redeployment: 21k loaded classes, 6k unloaded classes, 105 MB
PermGen = one extra instance of the app with 6k classes loaded,
nothing GC:ed. Assumed a total of 3 classloaders
Fourth redeployment: 21k loaded classes, 12k unloaded classes, 105 MB
PermGen = second(?) instance GC:ed and a new one loaded. Still 3
classloaders.
(Fifth redeployment: 15k loaded classes, 24k unloaded classes, 77 MB
PermGen = third and fourth(?) instance GC:ed and a new one loaded. 2
classloaders. Haven't repeated this test enough to build a thesis)
I should probably point out that garbage collection was forced a couple
of times before noting these numbers, so it shouldn't be a cased of
delayed GC.
--
</Mattias>
_______________________________________________
resin-interest mailing list
[email protected]
http://maillist.caucho.com/mailman/listinfo/resin-interest
