Interesting question ;) I did the change in classworlds because I
tested m3 trunk with java 7 and the classloaders weren't really
unloading, even after MNG-5386. What makes it interesting is that I
suppose they actually may unload on previous jdks but stopped doing so
on java7 due to classloader now being Closeable. They become very
clearly unloadable with java7 with this change, which should mean a
noticeable reduction in (permgen) memory usage for java7.

The most interesting side-effect of this change may actually be for
windows users, where I believe the file locks on jar files now get
properly released. Of course, there's workarounds in place for this
already....

I still wonder about the extensions though ;)

Kristian

2012/11/29 Igor Fedorenko <[email protected]>:
> Is this change expected to reduce or increase permgen use? Anything
> particular we should be looking for?

>
> FWIW, m2e embeds maven 3.0.4 and we don't have any problems (I know of)
> with with permgen. There are also no major permgen problems when running
> maven ITs in embedded mode. There are few thread leaks, but I don't
> think changes to classworlds can fix those.
>
> --
> Regards,
> Igor
>
>
> On 12-11-29 3:23 AM, Kristian Rosenvold wrote:
>>
>> I just deployed classworlds 2.4.1 which uses the jdk7 "close" method
>> on the classloader (if available) in the classworlds "dispose" method.
>> It looks to me like this radically changes permgen/memory usage on
>> embedded scenarios (some of you "embedded" guys might want to give
>> this a spin to quantify the exact results); my observations are only
>> from yourkit but they seem to be fairly substantial.
>>
>> I "observed" that the extension classloaders are not being
>> disposed/closed; what is their intended scope ? (Are they supposed to
>> be disposed?)
>>
>> Kristian
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to