Subject: Re: CGLIB memory usage within class loader
Newsgroups: gmane.comp.java.springframework.devel
Date: 2004-10-23 04:32:47 GMT (4 years, 36 weeks, 1 day, 19 hours and 13 minutes ago)
Patrick, >I just want to get this straight, since we run into this memory leak a > lot here when redeploying our app a lot in development: The leak is > caused by ThreadLocals that aren't cleaned up in Dom4j? That's correct. But there are other potential causes for such leak, there might be other things than DOM4J that would need to be fixed. > If so, I wonder what could be done in the Dom4j library to help this > situation, like maybe an API call that tells it to "clean up"? I don't really think it could work, because you can only clean up a ThreadLocal variable from the same thread you put it in. I took a look at DOM4J's source code, and it seems like they use ThreadLocal for thread safe cache (per-thread cache). There's three classes that use thing pattern. In two places it's for the factory instance that is returned from a static getInstance(). It doesn't seem appropriate to me to be using per-thread caching there. For the last use, I'm not really sure why it's needed, they are caching a instances of QNameCache, in which synchronization is used. If that class was intended to be thread safe, then I'm not sure why per-thread caching is used, and if it wasn't intended to be used concurrently, then I don't see why synchronization is used. To me, the best solution seems for DOM4J to just get rid of their current uses of ThreadLocal variables, I don't see any value in it. Guillaume ----- Original Message ----- From: "Patrick Burleson" <pburleson <at> gmail.com> To: <springframework-developer <at> lists.sourceforge.net> Sent: Friday, October 22, 2004 12:20 PM Subject: Re: [Springframework-developer] CGLIB memory usage within class loader >I just want to get this straight, since we run into this memory leak a > lot here when redeploying our app a lot in development: The leak is > caused by ThreadLocals that aren't cleaned up in Dom4j? > > If so, I wonder what could be done in the Dom4j library to help this > situation, like maybe an API call that tells it to "clean up"? > > Thanks, > Patrick > > > On Fri, 22 Oct 2004 00:50:33 -0400, Guillaume Poirier > <gpoirier16 <at> globetrotter.net> wrote: >> ----- Original Message ----- >> From: "Guillaume Poirier" <gpoirier16 <at> globetrotter.net> >> To: <springframework-developer <at> lists.sourceforge.net> >> Sent: Thursday, October 21, 2004 6:25 PM >> Subject: Re: [Springframework-developer] CGLIB memory usage within class >> loader >> >> >> I only wish A) there was a way to explicitly blow away the classloader >> >> or B) have hibernate be redeployable. One option is to place all the >> >> Hibernate related classes inside Tomcat's shared Classloader. This >> >> might reduce the amount of times I need to restart. >> > >> > Well, if you care enough, I'm pretty sure you could create a >> > ContextListener >> > that would cleanup when the context is destroyed. It would invole >> > reflection >> > to hack in private fields of the Threads though, so the solution might >> > fail >> > in different JVM, and wouldn't work well with SecurityManagers. >> > Basically, >> > what you would have to do is to get the list of all the system's thread >> > (through >> > ThreadGroup), and for each of them, iterate the "threadLocals" map, and >> > the "inheritableThreadLocals", to cleanup any instance for which the >> > ClassLoader is the current webapp or of child of it. >> > >> > You might also have to cleanup a few other things though, such as if >> > you >> > have >> > any JDBC drivers in your webapp's ClassLoader, they need to be >> > explicitly >> > unregistered, otherwise they will not be garbage collected. >> > >> > I create a prototype of a ContextListener that does that if you want. >> > >> > Guillaume > > > ------------------------------------------------------- > 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 > Springframework-developer <at> lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- 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