Interesting GC.start

[Haoqi Haoqi]

irb:
name='1'*1024*1024*100;nil # 100m
name=rand
GC.start
=============
$ ps -ef|grep irb
ax 14081 13958 0 14:57 pts/2 00:00:00 irb

$ top 14081
=============
14081 ax 20 0 114m 112m 1960 S 0 11.3 0:00.66 irb
14081 ax 20 0 13824 11m 1960 S 0 1.2 0:00.54 irb

 

[Robert Klemme]

irb:
name=3D'1'*1024*1024*100;nil # 100m
name=3Drand
GC.start
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
$ ps -ef|grep irb
ax =A0 =A0 =A0 14081 13958 =A00 14:57 pts/2 =A0 =A000:00:00 irb

$ top 14081
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
14081 ax =A0 =A0 =A0 =A020 =A0 0 =A0114m 112m 1960 S =A0 =A00 11.3 =A0 0:= 00.66 irb
14081 ax =A0 =A0 =A0 =A020 =A0 0 13824 =A011m 1960 S =A0 =A00 =A01.2 =A0 = 0:00.54 irb

Because the large string is eligible for collection.

but "name=3Dnil;GC.start",dont work

What do you mean? If "name=3Dnil" does not work you should probably
recompile your Ruby interpreter from the sources.

If you mean that you then do not observe a memory drop the reason is
that although the large string is eligible for collection there is no
guarantee when it will be collected. That's how automatic GC works -
and is supposed to work.

Cheers

robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

 

[Haoqi Haoqi]

but "name=nil;GC.start",dont work

If you mean that you then do not observe a memory drop the reason is
that although the large string is eligible for collection there is no
guarantee when it will be collected. That's how automatic GC works -
and is supposed to work.

Cheers

robert

"name=nil;GC.start" dont work:
I mean that then do not observe a memory drop.
And "name='1'*1;GC.start" it also works(observer a memory drop)

 

[Roger Pack]

irb:
name='1'*1024*1024*100;nil # 100m
name=rand
GC.start
============= ..

when "name=rand;GC.start", 112m->11m,why?

but "name=nil;GC.start",dont work

GC is tricky, because depending on what method calls, "ghost" references
to the original name might still exist on the stack.
You could try it with jruby/REE/1.9 to see if one of them works better,
but in this instance it appears that running "some methods" clears the
stack while others leave it dirty.
-r