Roger,

With native threading, each thread gets its own private stack managed by the
OS.
So, yes, in Ruby 1.9, there should not be any ghost references from one
thread's stack creeping onto another's.  However, there is still the
potential for ghost object references within any given thread's stack.

GC.limit= determines that number of bytes that will be allocated (or
reallocated)
before a garbage collection pass is automatically triggered.  It defaults to
8e6 bytes.  I set it to 2e6 bytes on memory limited embedded targets.
The process size will "breathe" by this amount of bytes while Ruby runs. 
Some might want to breathe deeper (and less often) if they've got bigger
lungs.
GC.limit is documented in ri as such.
It is the primary GC tunable.  If someone introduces a free list limit, they
can call it GC.freelist_limit.  I'm would not be confused by that.  

Nonetheless, if a couple more folks complain, I'll change GC.limit to
something longer.
I expect that it will get renamed in any case if it makes it into the
thrunk.

- brent



Roger Pack wrote:
> 
> On Mon, Jan 19, 2009 at 1:15 AM, Brent Roman <brent / mbari.org> wrote:
> 
>>
>> Yuki and Roger,
>>
>> I'm glad to hear these patches are working out well for you.
> 
> 
> I assume that with 1.9 this style patch isn't as necessary as threads
> don't
> "share garbage" between each other--is that right? [each thread could
> still
> clean itself, but at least they don't share garbage between threads--is
> that
> right?]
> 
> Also I might recommend renaming GC#limit to GC#malloc_limit or
> GC#alloc_limit since "limit" is somewhat ambiguous--is it a limit to the
> number of free pointers it will use? malloc size? [that type of thing].
> Thanks so much!
> -=r
> 
> 

-- 
View this message in context: http://www.nabble.com/-ruby-core%3A19846---Bug--744--memory-leak-in-callcc--tp20447794p21679891.html
Sent from the ruby-core mailing list archive at Nabble.com.