Hi,

Thanks for the clarification. The strange thing though (which lead me to
this conclusion) is that 1.8 consistently maintains

the same memory usage for both the include and the extend versions. Could
this be attributed to the frequency of GC runs?

Regards

oldmoe
oldmoe.blogspot.com

On Mon, Apr 20, 2009 at 5:43 AM, Yukihiro Matsumoto <matz@ruby-lang.org>wrote:

> Hi,
>
> In message "Re: [ruby-core:23252] [Bug #1392] Object#extend leaks memory on
> Ruby 1.9.1"
>     on Sun, 19 Apr 2009 07:18:18 +0900, Muhammad Ali <
> redmine@ruby-lang.org> writes:
> |
> |Bug #1392: Object#extend leaks memory on Ruby 1.9.1
> |http://redmine.ruby-lang.org/issues/show/1392
>
> |A few bytes are leaked every time Object#extend is called, here is a
> sample 1.9.1 script
>
> It does not leak memory.  the version that use #extend allocates
> internal class-like object for each hash object, so that it allocates
> lot more objects than #include version, thus requires more heap space
> to be allocated.  The GC does reclaim the unused objects, but it may
> not be able to return heap space to the underlying OS.
>
> To confirm there's no memory leak, replace sleep with
>
>  GC.start
>  p ObjectSpace.count_objects
>
> It prints the number of live objects, e.g.
>
> {:TOTAL=>17185, :FREE=>9590, :T_OBJECT=>5, :T_CLASS=>474, :T_MODULE=>20,
> :T_FLOAT=>6, :T_STRING=>1551, :T_REGEXP=>10, :T_ARRAY=>23, :T_HASH=>3,
> :T_BIGNUM=>2, :T_FILE=>3, :T_DATA=>28, :T_COMPLEX=>1, :T_NODE=>5451,
> :T_ICLASS=>18}
>
>                                                        matz.
>
>