Date: Wed, 20 May 2009 16:09:06 -0500 From: Dan Nelson <dnelson@allantgroup.com> To: Peter Steele <psteele@maxiscale.com> Cc: #freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: pthread_detach doesn't release memory Message-ID: <20090520210906.GH52703@dan.emsphone.com> In-Reply-To: <17302502.1751242850560962.JavaMail.HALO$@halo> References: <8793855.1731242850299553.JavaMail.HALO$@halo> <17302502.1751242850560962.JavaMail.HALO$@halo>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090520210906.GH52703>