cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Permgen, permgen
Date Mon, 22 Nov 2010 21:57:25 GMT
I read code in surefire and compiler. Plenty to read, nothing to reuse.

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
>

Mime
View raw message