cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Permgen, permgen
Date Mon, 22 Nov 2010 22:00:14 GMT
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 <dkulp@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,  <dkulp@apache.org> wrote:
> >> > On Nov 21, 2010, at 9:43 AM, Benson Margulies <bimargulies@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
> > dkulp@apache.org
> > http://dankulp.com/blog

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog

Mime
View raw message