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