From users-return-227865-apmail-tomcat-users-archive=tomcat.apache.org@tomcat.apache.org Tue Sep 20 19:12:00 2011 Return-Path: X-Original-To: apmail-tomcat-users-archive@www.apache.org Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3A5D178D4 for ; Tue, 20 Sep 2011 19:12:00 +0000 (UTC) Received: (qmail 84435 invoked by uid 500); 20 Sep 2011 19:11:56 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 84305 invoked by uid 500); 20 Sep 2011 19:11:56 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 84296 invoked by uid 99); 20 Sep 2011 19:11:56 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Sep 2011 19:11:56 +0000 Received: from localhost (HELO [192.168.23.9]) (127.0.0.1) (smtp-auth username markt, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Sep 2011 19:11:56 +0000 Message-ID: <4E78E579.70600@apache.org> Date: Tue, 20 Sep 2011 20:11:53 +0100 From: Mark Thomas User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Tomcat Users List Subject: Re: Executor thread lifecycle References: <4E78E186.7000005@apache.org> <4E78E347.7040107@apache.org> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org