From: "M. Edward (Ed) Borasky" <znmeb@...>
Date: 2007-08-12T10:38:38+09:00
Subject: Re: Interesting garbage collection article on LTU

Lionel Bouton wrote:
> Hi,
> 
> I just read the abstract on http://lambda-the-ultimate.org/node/2391 and
> found it might be of interest for core language developers and people
> interested in garbage collecting.
> 
> I immediately thought of Ruby because of my experience with long running
> Rails processes. It might be the occasion to have my gut feelings
> checked by people that really know the inner workings of Ruby 1.8 too.
> 
> 1/ From my experience the memory usage of a Ruby process never goes down
> (garbage collected objects only free memory for future reallocation, but
> the process memory is never recompacted after garbage collecting).
> 2/ The VM load can remain high after big allocations and subsequent
> garbage collections (ie: there's some pagging going on even if the
> application isn't doing memory intensive operations anymore).
> 
> The article above might just have explained to me why Ruby behaves this
> way: the GC might just force paging once the memory footprint of a
> process is large enough, even if most of this process-allocated memory
> is actually free room.
> 
> Now going to review the content more in depth.
> 
> Lionel.
> 
> 
I guess I need to go read the article first, but clearly number 2 is
going to be operating system and C language run time dependent. Ruby
isn't the only garbage-collected language that can have bad interactions
with an OS -- I've seen nasty things happen in the R Windows
implementation, for example, even though the garbage collector there
*has* brought the overall process/thread memory allocation down.

And Linux is notoriously proud of the mantra "free memory is wasted
memory". It usually won't kick a page out to disk until it needs it for
something else. So the resident set size of a Linux process/thread may
have little or nothing to do with its actual working set.