From: Kurt Stephens Date: 2010-12-24T04:18:03+09:00 Subject: [ruby-core:33844] Re: PATCH: REE fast-thread.patch: stack_free() not called in rb_thread_die(). On 12/23/10 8:03 AM, KOSAKI Motohiro wrote: > 2010/12/23 KOSAKI Motohiro: >>> Similar technique might be relevant in MRI 1.9 if fiber/continuation stacks >>> are also not freed until GC. >>> >>> On 12/22/10 11:32 PM, Kurt Stephens wrote: >>>> >>>> http://code.google.com/p/rubyenterpriseedition/issues/detail?id=57 >>>> >>>> Helps reduce memory usage for short-lived Threads that might not be GC >>>> fast enough. >>>> >>>> Might be relevant to other MRI builds with the fast-thread.patch. >> >> FWIW, Recent linux glibc malloc has some optimization for it. Can you try >> recent glibc + 64bit linux combination? > > And, MALLOC_MMAP_THRESHOLD_ might help you even if you are using old > distribusions. > I guess. > malloc() is not the issue; the fast-thread.patch uses mmap()/munmap() directly for Thread stack space. The patch at the link allows REE (with fast-thread.patch applied) to call munmap() sooner after the Thread dies instead of waiting until GC. We found that Threads tended to not be GCed as often as we like (hundreds of them), and with each Thread stack consuming 1MB... Stock MRI 1.8.7 does not have this problem; it calls stack_free() in rb_thread_die(). This is only a problem when fast-thread.patch is applied. The fast-threads.patch cannot always call stack_free(), sometimes because the CPU %sp is in the dieing Thread's stack space, particularly when the Thread dies naturally. It appears MRI 1.9 cont.c frees continuation stack buffers on context switches and does not jump the CPU %sp into it, it copies stack buffers back and forth. I could be wrong, I'm more familiar with MRI 1.8.