From: Eric Mahurin <eric_mahurin@...>
Date: 2005-10-17T02:33:19+09:00
Subject: Re: Help! define_method leaking procs...

--- ES <ruby-ml@magical-cat.org> wrote:
> > So your definition of "memory leak" says that it is not a
> memory
> > leak if the unused memory can still be freed by the
> program. 
> 
> Yes. As far as I knew, this was the only sensible definition.
> If there is a problem, it is not a memory leak (as most or
> all
> C programmers understand the term anyway); changing the term
> might
> yield a more successful debate.

Try a google on "memory leak".  The first several defintions
you'll find are more general and not limited to languages that
don't have automatic GC.  Just because you have a perfect
language with perfect GC doesn't mean you can't write a program
that "leaks" memory - over time uses more and more memory when
it doesn't need it.  I think the language/GC/libs should try to
plug as many holes as possible, but you still won't be able to
prevent all memory leak bugs of programs written in the
language.

> > With the example I gave, you could still free the memory
> using
> > the Proc#binding with eval to assign the unused variables
> to
> > nil.  But, here is a slightly modified example where (using
> > #define_method) where you lose this access:
> > 
> > n=2**13;(1..n).each{|i|
> >
>
a=(1..i).to_a;self.class.send(:define_method,:"f#{i}"){i*i}};GC.start;
> >
>
IO.readlines("/proc/#{Process.pid}/status").grep(/VmSize/).display'
> > VmSize:   172028 kB
> > 
> > As far as I know, you can't access any of thoses a's after
> you
> > get out of the each loop.  I call that a memory leak by any
> > definition.
> > 
> > Here is the fixed version:
> > 
> > ruby -e '
> > n=2**13;(1..n).each{|i|
> >
>
a=(1..i).to_a;self.class.send(:define_method,:"f#{i}"){i*i};a=nil};GC.start;
> >
>
IO.readlines("/proc/#{Process.pid}/status").grep(/VmSize/).display'
> > VmSize:    11504 kB



		
__________________________________ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs