[ruby-core:21537] Re: [Bug #744] memory leak in callcc?

On Thu, Jan 22, 2009 at 4:09 PM, Brent Roman <[e-mail]> wrote:

>
> Michael,
> I'm glad you are taking this on.  Thanks.  It must have been a tedious job.
> See comments below --->
>

At my company we are running several copies of 2 Rails applications which we
have to restart on a regular basis because of the Ruby memory leak. This
patch has the capability of ending that. Tedious or not it is worth the
effort. The memory savings is an added bonus the may let us run more copies.

I am also working with a copy of 1.8.6 patched with a GC stats patch
discussed here: http://blog.pluron.com/2008/02/memory-profilin.html to aid
in performance testing and profiling our applications. And I have also been
investigating Phusion's Ruby Enterprise Edition, the changes to make the GC
copy-on-write friendly could give us a benefit.

Combining all these patches gets a little tricky in a couple places, if I
need to I will use a GC stats patched MRI for performance and profiling and
MBARI patched for production to save memory. The REE copy-on-write is just
an added bonus.


>
> Michael King-2 wrote:
> >
> > I have applied the MBARI patches to 1.8.6 p287. About half the hunks had
> > to
> > be applied by hand. In doing so I noticed 1 hunk that looked odd. The
> hunk
> > was in gc.c, in the function ruby_xmalloc, the odd line is:
> >    if ((malloc_increase+=size) > malloc_limit) {
> >
> > was is intended to change the value of malloc_increase in the if
> > statement?
> >
> > --->  Yes, that is the intent.  You will see this in ruby_xrealloc() and
> > ruby_xmalloc()
> >         Doing it this way saves a jump at the machine code level.


Ok, this was the only instance that I saw and I know I have done code like
this when I wasn't intending to, so I wanted to double check.

>
> >
> > When running test/runner.rb for the patched Ruby I am seeing the follwing
> > error and failure:
> >
> >   1) Failure:
> > test_should_propagate_signaled(TestBeginEndBlock)
> > [./test/ruby/test_beginendblock.rb:82]:
> > <""> expected to be =~
> > </Interrupt$/>.
> >
> > --->  I see this quite often with both patched and unpatched Ruby.
> >         Does anyone know why?
> >
> >
> >   2) Error:
> > test_object_id_collision(YAML_Unit_Tests):
> > RuntimeError: id collision in ordered map
> >     ./test/yaml/test_yaml.rb:1281:in `test_object_id_collision'
> >
> > --->  This one is worrisome.  I've never seen it.
> >         I've never run tests against unpatched 1.8.6
> >         Do either of these failures occur there?


I have done multiple runs now with my unpatched copy of Ruby 1.8.6 and I
have seen 0 failures and 0 errors.

I also did a run of 1.8.7 patched and unpatched and both had 0 error and 0
failure.

I am doing this round of compiling and testing on Ubuntu 8.04 with gcc
4.2.4. I have tried compilations with the CFLAGS listed with the code and no
CFLAGS, doesn't change the outcome. our deployment environment is Ubuntu
6.06 so I will be running the tests there as well.

>
>
> Monitor the process size while running the test suite.
> If MBARI7 is working properly, you should observe that the size of the main
> test process
> near the end of its run is about 30MB less than when running with unpatched
> 1.8.6.
>
> - brent
>

This is interesting.... I will rerun the tests tomorrow, I'm done for
tonight.

Unpatched Ruby 1.8.6 capped out at 94M
Ruby 1.8.6 patched with MBARI and GC-stats capped out at 42M
Ruby 1.8.6 patched with MBARI capped out at 53M


- Michael