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
        dnel...@allantgroup.com
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to