Path: csiph.com!x330-a1.tempe.blueboxinc.net!feeder1.hal-mli.net!feeder.news-service.com!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!talisker.lacave.net!lacave.net!not-for-mail From: JK Victor Newsgroups: comp.lang.ruby Subject: Re: Manual Memory Management and Automatic Garbage Collection Date: Wed, 18 May 2011 18:50:54 -0500 Organization: Service de news de lacave.net Lines: 18 Message-ID: References: <24b916bbe5f647533b379407fffb83e9@ruby-forum.com> <313bbaeb2103f9ad4323556c4fc5730f@ruby-forum.com> NNTP-Posting-Host: bristol.highgroove.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: talisker.lacave.net 1305762856 21561 65.111.164.187 (18 May 2011 23:54:16 GMT) X-Complaints-To: abuse@lacave.net NNTP-Posting-Date: Wed, 18 May 2011 23:54:16 +0000 (UTC) In-Reply-To: X-Received-From: This message has been automatically forwarded from the ruby-talk mailing list by a gateway at comp.lang.ruby. If it is SPAM, it did not originate at comp.lang.ruby. Please report the original sender, and not us. Thanks! For more details about this gateway, please visit: http://blog.grayproductions.net/categories/the_gateway X-Mail-Count: 383457 X-Ml-Name: ruby-talk X-Rubymirror: Yes X-Ruby-Talk: Xref: x330-a1.tempe.blueboxinc.net comp.lang.ruby:4749 Tridib Bandopadhyay wrote in post #999550: > So I > was thinking of not letting the GC to come and free memory every time > for small objects,Stopping the code. So I just want to check if it can > be helpful or not... Ruby has a very primitive conservative GC -- it just scans the stack looking for pointers. If you are a time traveler from the 1950s then Ruby's GC might be an interesting study. In any case it would be easy to fool Ruby's GC, if that's what you wish: allocate a pointer and hide data behind the pointer. The GC won't see pointers which aren't on the stack. You can manage that GC-concealed data however you like. -- Posted via http://www.ruby-forum.com/.