Menu
▾
▴
Re: [Springframework-developer] RE: CGLIB memory usage within class loader
|
From: <jue...@we...> - 2004-10-19 21:28:27
|
Rob,
=20
I haven't committed the changes yet, because I need to merge in your =
changes from the afternoon first :-) Will do so tomorrow morning. It =
would probably be good for you to wait until I've committed, to avoid =
any further merging conflicts...
=20
Your recent changes have to do with using non-default constructors on =
CGLIB proxies, as far as I see. Is this already fully working?
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Rob Harrop
Gesendet: Di 19.10.2004 20:04
An: spr...@li...
Betreff: Re: [Springframework-developer] RE: CGLIB memory usage within =
class loader
Jurgen/All,
I'll check into this some more and see if I can reduce the memory usage
of the proxy classes. On another note I can't see the changes that
Jurgen has made, I made some changes about two hours ago and they seem
to have committed.
Rob
j=FCrgen h=F6ller [werk3AT] wrote:
>BTW, I've polished Cglib2AopProxy's source code quite a bit: for =
example, it logs at debug level now (rather than info), and uses =
formatting consistent with the rest of Spring's sources.
>
>I've actually already done this polishing a second time: The earlier =
one got lost. It shows up in CVS, but then seems to have got overwritten =
by a subsequent commit. There was also a JDK 1.4 dependency fix in there =
(Boolean.valueOf with a boolean argument), which got lost too.
>
>So please, when you merge before a commit, double-check that you're not =
losing updates that someone else applied before you! It wasn't a big =
issue this time, but what if we don't notice it next time...
>
>Juergen
>
>
>-----Original Message-----
>From: j=FCrgen h=F6ller [werk3AT]
>Sent: Tuesday, October 19, 2004 6:35 PM
>To: spr...@li...
>Subject: CGLIB memory usage within class loader
>
>
>I've just been made aware of the following by a werk3 colleague: When =
repeatedly creating CGLIB proxies for the same target class but for =
different advices - within the same class loader -, you'll create new =
proxied classes all the time, which won't get removed for the lifetime =
of the classes.
>
>The generated classes themselves are not the problem here. However, =
each of those proxy classes seems to hold strong references to its =
advices and target object, through holding the ProxyCallbackFilter =
instance that was passed into the Enhancer on proxy creation. Note that =
the proxy *class* holds that reference, not the proxy *instance*.
>
>The effect is that you can easily run out of memory if your advices or =
target objects occupy a large amount of memory, as none of those objects =
will get garbage collected as long as the CGLIB-generated proxy class is =
still hanging around in the class loader. This does *not* happen at all =
with JDK dynamic proxies.
>
>Of course, such excessive proxy creation is not the usual case in a =
production application. Web app restart is not a problem either, as the =
class loader will be shut down (releasing the CGLIB-generated proxy =
classes). The usual scenario where this memory leak becomes a problem is =
test suites, with application contexts getting created per test method.
>
>The following code snippet reproduces the issue:
>
> while (true) {
> ProxyFactory proxyFactory =3D new ProxyFactory();
> proxyFactory.setTarget(new TestBean() {
> private byte[] field =3D new byte[1000000];
> });
> proxyFactory.addAdvice(new DebugInterceptor());
> proxyFactory.setProxyTargetClass(true);
> TestBean tb =3D (TestBean) proxyFactory.getProxy();
> Thread.sleep(100);
> }
>
>Depending on the max memory available to the VM, you'll run into an =
OutOfMemoryError sooner or later, as the target TestBean instance with =
its byte array of size 1000000 never gets garbage collected. Note that =
this does *not* happen when removing the addAdvice call, as we're just =
generating a single CGLIB proxy class then.
>
>Is this behavior unavoidable? What do we recommend for such testing =
scenarios then? In particular for integration tests with Hibernate, a 5 =
MB leak per context creation is not really acceptable. Of course it's =
preferable to share the application context as far as possible, but =
there are still valid use cases for repeated creation...
>
>Juergen
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IT Product Guide on =
ITManagersJournal
>Use IT products in your business? Tell us what you think of them. Give =
us
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out =
more
>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>=20
>
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give =
us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out =
more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
