From: "Muhammad A. Ali" Date: 2009-04-20T23:22:58+09:00 Subject: [ruby-core:23263] Re: [Bug #1392] Object#extend leaks memory on Ruby 1.9.1 --00163649906935341d0467fd4493 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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 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. >> >> > --00163649906935341d0467fd4493 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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

@extend =3D ARGV[0]

module B= etterHash
=A0 def blabla
=A0 end
end

unless @extend
=A0 = class Hash
=A0 include BetterHash
=A0 end
end

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

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

This way the allocation is done i= n batches and the GC should be able to free the objects after each batch. <= /p>

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 ti= ll 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 mo= re memory gradually.

To further prove I added the following code befo= re the end:

@strings =3D []
10240.times do
=A0@strings <<= "a"*1024=A0
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 increas= e 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 clarificatio= n. 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 r= uns?

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 memo= ry on Ruby 1.9.1"
|A few bytes are leaked every time Object#extend is called, here= is a sample 1.9.1 script

It does not leak memory. =A0the 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. =A0The 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

=A0GC.start
=A0p ObjectSpace.count_objects

It prints the number of live objects, e.g.

{:TOTAL=3D>17185, :FREE=3D>9590, :T_OBJECT=3D>5, :T_CLASS=3D>47= 4, :T_MODULE=3D>20, :T_FLOAT=3D>6, :T_STRING=3D>1551, :T_REGEXP=3D= >10, :T_ARRAY=3D>23, :T_HASH=3D>3, :T_BIGNUM=3D>2, :T_FILE=3D&g= t;3, :T_DATA=3D>28, :T_COMPLEX=3D>1, :T_NODE=3D>5451, :T_ICLASS=3D= >18}

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0matz.



--00163649906935341d0467fd4493--