tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Checkoway <>
Subject Re: Executor thread lifecycle
Date Tue, 20 Sep 2011 19:06:52 GMT
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

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 <> 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 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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message