On 20/09/2011 20:06, Dan Checkoway wrote: > To be specific, we're having a major issue with garbage generation. To > avoid this, we're pre-allocating pools of instances (up until now > ThreadLocal, but that's obviously changing). When a request is processed it > may need anywhere between 1 and N objects from the pool, which it grabs and > uses, and then returns them to the pool when finished. If N > pool size, > new instances get allocated on the fly, and they get added to the pool as > well. > > Sounds like a big memory leak in the making, right? Yeah, except there's a > rational cap on the total # of instances each thread will ever need. So > this ended up being dramatically more efficient because it generated > essentially zero garbage over time. GC could keep up again... > > Until this proved to be its own garbage generator. :-) As threads got > recycled, the ThreadLocal pools got turned to garbage. Foiled again! :-) > > So yeah, I'm going to centralize the pool and just synchronize management of > it. Oy.
You might want to take a look at Commons Pool trunk. It has been completely re-written for 2.0 for performance. There is still some work to do before a release but the GenericObjectPool should be OK and performs well in a multi-threaded environment (the GenericKeyedObjectPool has a known bug I need to fix). Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
