[ruby-core:20534] Re: Promising C coding techniques to reduce MRI's memory use

Roger,

Look for the "real patch" next week.
In fact, there will be at least five patches:

#1:  prevents continuations from segfaulting when they refer to dead threads
#2:  limit each thread's stack to its own stack frames (none from other
threads)
#3:  My stack clearing patch
#4:  factor rb_eval() to reduce the size of its stack frame
#5:  replace recursive stack_extend() in eval.c, replace GC.stress with
GC.limit=

My stack clearing patch is quite small, however it does tend to clear
the same areas repeatedly.  The difficultly I had avoiding this was that
one could not know exactly when the GC would occur.  If it always 
kept occurring when the stack was deep, clearing the stack just
before GC would have no real effect on the "ghost references" still
on it.  I'd be interested if anyone knows a way to cope with
this without repeated zeroing the stack "just in case" whenever it is
shallow.

In any case, like you, I didn't notice any measurable slowing of Ruby
due to clearing the stack this way -- just much reduced memory
usage.  It may well be that the time for stack clearing is more than
offset by the quicker GC passes.

- brent


Roger Pack wrote:
> 
> 
> This is sweet.  I liked the idea so much I coded my own [perhaps much
> smaller, definitely less effective] version.  It only includes the
> stack clearing you referred to, and doesn't even monitor "exactly" the
> stack size, but approximates it by metering it once every CHECK_INTS.
> Ruby seems to run "as fast as normal" with it, and collect better.
> 
> In principle, you'd only have to clear the stack once "between each
> GC" so if you kept track of which portions of it you'd been able to
> clear, you could avoid a few stack clearings :)
> I'm not sure exactly how much cpu that would save, though.
> 
> This patch also doesn't fix the
>  loop {@x=callcc{|c|c}}
> aspect [presumably because ruby's green threads copy chunks of the
> stack to heap, so they aren't cleaned]--so I'd imagine it's less
> effective in multi-threaded codes [but hopefully still helpful].
> 
> Look forward to the real patch when it comes in :)
> 
> 

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