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

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