Benson, Your analysis assumes that a class generated and loaded by the reflection code in the JRE can only be garbage collected if the class loader is garbage collected. Are you sure about that? I'm pretty sure that I've seen this type of classes being unloaded before the class loader was garbage collected.
Andreas On Sun, Nov 21, 2010 at 16:53, Benson Margulies <[email protected]> wrote: > Now you've made the mistake of showing some interest in this :-) > > Consider this line from the yourkit trace. > > "#6666","2:34.164","main","WSDLManagerImpl.loadDefinition","sun.reflect.GeneratedConstructorAccessor65","loaded" > > Someone has done something reflective that creates a class, and that > class sticks around. > > I suspect that the WSDLFactory is the culprit here. Got any ideas for > how to force it into the context class loader? > > > On Sun, Nov 21, 2010 at 10:34 AM, <[email protected]> wrote: >> >> >> On Nov 21, 2010, at 9:43 AM, Benson Margulies <[email protected]> wrote: >> >>> I see two apparent sinks of permgen in our build from yourkit. >>> >>> One is the XSD-to-Java mojo, which doesn't belong to us. But we might >>> be able to wrap it in such a way as to change its behavior. > > > >> >> Or just use the cxf-xjc-plugin that we do have control over. >> >> Dan >> >> >> >>> >>> The other is the SOAPBindingUtil.getProxy. The proxy classes, which >>> co-locate in the class loader of the classes they proxy, never go >>> away. >>> >>> So, they end up in the per-plugin class loader, which isn't going to >>> go away for the life of the build. >>> >>> So, it looks like we need an additional classloader in the path here >>> that can be GC'd. >>> >>> The WSDL2Java mojo is the top of this. >>> >>> Question: should SOAPBindingUtil just use the thread context class >>> loader, which would allow us to easily deal with this in the mojo, >>> instead of sticking the proxies into the same class loader as the >>> things proxied? >>> >>> I think so. >> >> >
