On Monday 22 November 2010 4:57:25 pm Benson Margulies wrote: > I read code in surefire and compiler. Plenty to read, nothing to reuse.
I was somewhat afraid of that. :-( Dan > > This is a bit big for me to tee off on right now, so I'm going to see > if there are any other takers before I try. > > On Mon, Nov 22, 2010 at 11:07 AM, Daniel Kulp <dk...@apache.org> wrote: > > On Sunday 21 November 2010 12:10:37 pm Benson Margulies wrote: > >> So, there's a question of approach here. > >> > >> The general situation I find is this: maven creates a class loader per > >> plugin. it hangs onto that for the life of the build. Any class that > >> the plugin touches ends up in there, essentially strongly references. > >> So anything referenced strongly in, say, a static of one of those > >> classes, or anything held in a weak map keyed by that class loader, is > >> not going anywhere. > >> > >> The xsd-to-java mojo that we own can sure drag in a lot of classes, as > >> well as some proxies and generated classes from reflection. > >> > >> All things considered, I think it needs a forkMode. It's possible that > >> the wsdl2java mojo should get the same treatment. Without a forkMode, > >> what we're faced with is some rather elaborate attempt to subvert > >> maven's preference to keeping the class graph of a plugin around for > >> the entire build. By the time we've run the testutils build, well, > >> we've eaten a whole lot-o-permgen this way. > > > > Yea. We definitely could use a fork mode. Right now, we cannot really > > test the jaxws 2.2 stuff as that would require a fork mode with some way > > of setting endorsed things. It also makes it much harder for our USERS > > to use the maven plugins to do jaxws 2.2 things. > > > > Thus, +1 for a fork mode. I wonder if surefire has some code in there > > to use as an example. > > > > Dan > > > >> Thoughts? > >> > >> On Sun, Nov 21, 2010 at 10:34 AM, <dk...@apache.org> wrote: > >> > On Nov 21, 2010, at 9:43 AM, Benson Margulies <bimargul...@gmail.com> > > > > 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. > > > > -- > > Daniel Kulp > > dk...@apache.org > > http://dankulp.com/blog -- Daniel Kulp dk...@apache.org http://dankulp.com/blog
