Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (athena.apache.org: domain of bimargulies@gmail.com
 designates 209.85.214.41 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=ou5I+dILMgR2eZemuYkXsMMXjNrSH/9w2C/yRyGWR/uRLZYvnpZK6g0CISHxQIIzSA
         +Vv1lEF9QxLyidwwKqmsWernG8gWcEgoHS2XUUGbktYHgjaAhZfsE28c02Wl/FDVIJal
         +lnITeXHXnO3wEk8TyoNYEsbq221fJ+Gx9cKc=
MIME-Version: 1.0
In-Reply-To: <72573857-4806-4872-976E-66C177689B09@apache.org>
References: <72573857-4806-4872-976E-66C177689B09@apache.org>
Date: Sun, 21 Nov 2010 10:53:40 -0500
Message-ID: <AANLkTimfY8fbbQ6UC8FQ3o2qT_fG5h==AJTNGTRMxuLD@mail.gmail.com>
Subject: Re: Permgen, permgen
From: Benson Margulies <bimargulies@gmail.com>
To: dkulp@apache.org
Cc: dev@cxf.apache.org
Content-Type: text/plain; charset=UTF-8

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,  <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.
>
>