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. On Tue, Sep 20, 2011 at 3:02 PM, Mark Thomas <ma...@apache.org> wrote: > On 20/09/2011 19:59, Dan Checkoway wrote: > > Thanks for the quick reply, Mark. Much appreciated. I was afraid that > was > > the case. > > > > What I was trying to accomplish was...data that's not request/response > > specific in any way, that survives requests. I was using ThreadLocal so > as > > to make it non-blocking, i.e. I didn't want to centralize management of > this > > stuff and have to synchronize access to it across my hundreds of executor > > threads. > > > > Sounds like I'll need to bite the bullet on that. Oh well... :-) > > I assume it changes rarely (and you would have had to deal with that > even if using ThreadLocals and had the same concurrency issues). A > read/write lock should do the trick if reads >> writes. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
