On second thoughts, I still believe there is a leak. I modified the test as
follows:

@extend = ARGV[0]

module BetterHash
  def blabla
  end
end

unless @extend
  class Hash
  include BetterHash
  end
end

t = Time.now
100.times do #split the allocation process
  10000.times do
    s = {}
    s.extend BetterHash if @extend
  end
  GC.start # force a gc after each allocation batch
end

after = Time.now - t
puts "done with #{GC.count} gc runs after #{after} seconds"

This way the allocation is done in batches and the GC should be able to free
the objects after each batch.

After the first few batches the vm should have enough free space for any of
the next ones. Not what happens

though as it keeps growing till it reaches like ~18 MB on my machine. (the
include version maxes at 2.8).

If I add a delay between batches I could watch the process as it uses more
memory gradually.

To further prove I added the following code before the end:

@strings = []
10240.times do
 @strings << "a"*1024
end

This will alocate around 10MB worth of small strings (1K each). The include
version reports an increase of 10MB in its RAM usage.

The troubling thing is that the extend version also reports a 10MB increase
in its RAM usage (up to ~29) when it has supposedly

more than enough heap space to allocate those small strings.
thoughts?
oldmoe
oldmoe.blogspot.com
On Mon, Apr 20, 2009 at 3:23 PM, Muhammad A. Ali <oldmoe@gmail.com> wrote:

> 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.
>>
>>
>