Before hacking rb_eval(), I first tried finding some compiler 
options that would fill the stack holes.  

Decreasing the stack slot alignment requirements
does pack stack somewhat, however, the very sparse stack 
frame generated by the huge switch statement in rb_eval() remains
largely unaffected by any compiler options I could find.
These holes still caused the GC to preform poorly for my app and
to fail utterly when presented with:  @x=loop {callcc {|c| c}}

Just have a look at the generated assembler code for rb_eval:
from "gcc -S -O2 eval.c".  The function preamble decrements stack pointer by 
566 bytes.  Which of those bytes is actually written is determined
by the node type processed.  Most of them remain uninitialized in *all*
cases.
With -mpreferred-stack-boundary=2, rb_eval() starts by decrementing
the stack pointer by 548 bytes.  No much difference.

After factoring, rb_eval() decriments the stack pointer by
only about 20 bytes.  I got best results with these options on x86 gcc
4.3.2:

gcc -mpreferred-stack-boundary=2 -fno-stack-protector
-fno-inline-functions-called-once

Nobu, these are not just 2%-5% memory and time reductions.
For multithreaded applications, the both time and space performance
are significantly improved.  I suspect that some large single threaded
apps will also benefit.  (Maybe even rails?! :-) 

There's an opportunity here.  I hope that
the core developers will find time to seriously explore it.

- brent


Nobuyoshi Nakada-2 wrote:
> 
> Hi,
> 
> At Fri, 28 Nov 2008 18:54:45 +0900,
> Brent Roman wrote in [ruby-core:20149]:
>> Longer term,
>> The stack clearing could be supplied as a small patch to the 1.8 series,
>> however the
>> refactoring of rb_eval() is probably too large to be attached to an email
>> message
>> on this list.  I will take the time to produce these patches only if at
>> least a few people
>> commit to testing them,  reporting detailed results and suggestions for
>> improvement here.
> 
> In shorter, if you use gcc, can't you try -mpreferred-stack-boundary=2
> option?
> 
> -- 
> Nobu Nakada
> 
> 
> 

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