Comment #11 on issue 643 by [email protected]: ClassLoader leaks in IndicesCallbackFilter
http://code.google.com/p/google-guice/issues/detail?id=643
Results of further investigation when using the original testcase from #c2 with Guice trunk: adding System.gc() inside the test loop allows GC to collect at least one of the proxy classloaders and all of the test instances and interceptors. This shows that it's not as simple as a stray strong reference causing this leak.
Instead the underlying issue seems to be that CGLIB uses a static WeakHashMap in its generator, using the proxy classloader as the weak key and storing details such as the callbacks under the value. Unfortunately WeakHashMaps are only cleared when they mutate - so in this example the callback table will be kept alive until another enhanced class is generated, at which point the map will mutate and the original table will be reclaimed.
Adding weak references to IndicesCallbackFilter works around this issue by breaking the indirect link from the WeakHashMap's reference queue back to the proxied class. Note that the callback table will still be held in the map's queue waiting to be reclaimed, but the extra weak references mean the proxy classloader can at least be unloaded.
PS: I attempted to extend the BytecodeGenTest to test this scenario, but unfortunately (depending on your perspective) the interceptor classloader is always GC'd. Looks like more work is needed to recreate this as a repeatable unit test.
-- You received this message because you are subscribed to the Google Groups "google-guice-dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.
