From owner-freebsd-questions@FreeBSD.ORG Wed May 20 21:09:09 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DD06106566B for ; Wed, 20 May 2009 21:09:09 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id 349848FC30 for ; Wed, 20 May 2009 21:09:09 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id n4KL98gP012328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 May 2009 16:09:08 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id n4KL97lE067056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 May 2009 16:09:07 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.3/Submit) id n4KL96Nn067055; Wed, 20 May 2009 16:09:06 -0500 (CDT) (envelope-from dan) Date: Wed, 20 May 2009 16:09:06 -0500 From: Dan Nelson To: Peter Steele Message-ID: <20090520210906.GH52703@dan.emsphone.com> References: <8793855.1731242850299553.JavaMail.HALO$@halo> <17302502.1751242850560962.JavaMail.HALO$@halo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17302502.1751242850560962.JavaMail.HALO$@halo> X-OS: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: ClamAV version 0.94.1, clamav-milter version 0.94.1 on email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Wed, 20 May 2009 16:09:08 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: #freebsd-questions Subject: Re: pthread_detach doesn't release memory X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2009 21:09:09 -0000 In the last episode (May 20), Peter Steele said: > I should have provided a little more detail. Even if I strip my thread > function down to nothing more than this: > > void *mythread(void* param) > { > pthread_exit(NULL); > } > > my application still grows by 128 bytes each time I spawn a thread with > this function. There is no explicit memory for me to deallocate, and my > understanding was that by using pthread_detach then any temporary > structures allocated by the OS would be released when the thread > terminates. This doesn't seem to be the case though, so I'm assuming I'm > doing something wrong but I do not know what. > > I use the follow simple app to test this behavior: > > int main() > { > getchar(); > pthread_t thread; > pthread_create(&thread, NULL, mythread, NULL); > getchar(); > printf("done"); > getchar(); > } > > When I hit the first getchar, I check the application's size using ps from > another terminal window. It shows 12312k. I then allow the application > to proceed to the next getchar, and again check its size with ps. It > shows 12440k. Finally, I let it proceed to the final getchar, and again > ps shows 12440k. Even if I wait a while the size remains at 12440, and if > I create additional threads, then each one adds to the application's > footprint. > > What am I missing? The free() function isn't guaranteed to release memory back to the OS; it just makes it available to the process for another malloc(). Large allocations that libc used mmap() to allocate memory for might actually get returned to the OS immediately. Small allocations are placed in pages with similar-sized ones, and all would have to be freed before the page can be reclaimed. Even when the page does free, libc won't return it immediately to the OS, to avoid extra overhead if your process calls a similar malloc() again. If I add a loop to your main() function, and add your missing pthread_detach() call, here's the memory usage I see on each iteration: 2220 2348 2476 2604 2732 2860 2860 ... no change after here So it reached a steady state after 5 loops. See these links for the gory details: http://svn.freebsd.org/viewvc/base/head/lib/libc/stdlib/malloc.c?view=markup http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf -- Dan Nelson dnelson@allantgroup.com