First thanks for doing all that hard work.  I'm sure it's not pleasant
to try and figure this all out, and you seem to have done a very
thorough job :)

A few questions.

> Process Size Inital/Final       User's CPU time (from the time command)
> Unpatched 1.8.7-p72:     30MB/97MB      92 seconds
> MBARI 6 atop 1.8.7-p2:   30MB/57MB    100 seconds

Is this the time to complete test-all?

I wonder why it uses more total time... :) [the RAM usage looks nice
though].  Makes me wish we had similar patches for 1.9, too [running
make test-all on 1.9 for me typically uses like 400MB RSS for some
reason...].


> The patched version reports one additional failure:
>  2) Failure:
> test_should_propagate_signaled(TestBeginEndBlock)
> [./ruby/test_beginendblock.rb:81]:
> <""> expected to be =~
> </Interrupt$/>.

Does it report this consistently?

Interestingly, with 1.8.6 HEAD on mingw currently I get this:

 3) Failure:
test_should_propagate_signaled(TestBeginEndBlock)
[../ruby_1_8/test/ruby/test_beginendblock.rb:83]:
<nil> expected but was
<3>.

> And, the drb test segfaults with the patched version.
> (so I removed it for both the patched and unpatched for comparason)

Maybe you could post a gdb backtrace [in case someone can figure out
what's going on...]

Question--The install instructions mention using
-mpreferred-stack-boundary=2, though in the writeup it says it helps
only slightly--but you recommend it because it still helps?

re MBARI2: gc sometimes segfaults: do you have any examples of how it
does this?  So these old frames are collected but not really--is that
what happens?

re: MBARI3 is it possible to use memzero to forcefully overwrite local
variables [though as you pointed out, it would still leave
temporaries].  Are there any other culprits besides rb_eval [and
doesn't eval get called fairly rarely so this isn't a help for most
progs?]

You mention that after this the callcc stuff should work--do you think
that only applying this one patch should be sufficient for that to
happen?

why remove the dynamic malloc_limit?
One thing you might want to try would be the ruby benchmark suite with
and without [1].

MBARI5 : ruby extends the stack when it needs to thread shift from a
"smaller stack" thread to a larger stack thread, is that right?  After
shifting to a smaller stack might be a good time to clean the stack...

re: MBARI6 question: why are these included with 5 other gc patches?
[besides that they're cool and useful]?  Might be convenient to just
include the 1.9 style syntax by default [I might could come up with a
patch for it].:)

re: sourceref--it might be convenient to tie in with SCRIPT_LINES__
stuff, perhaps [thanks to nobu for pointing out its existence recently
to me].

I suppose my only wish list for these would be that it didn't clear
the stack but once per thread per GC.  I might could help out sometime
with it.

Thanks much for your work on these.  I'll give them a shot on windows
mingw/linux by next weekend.
Cheers.
-=r
[1] http://github.com/acangiano/ruby-benchmark-suite/tree/master