On Thu, 20 Dec 2001 20:59:07 +0900
kjana / dm4lab.to (YANAGAWA Kazuhisa) wrote:

> Additionally, it may be an item of the C FAQ: free()ing a malloc()ed
> memory block does not means the block to be returned to underlying OS.
> I'm not sure Windows task manager shows what as allocated memory, but
> likely it is memory usage of the process.  Since memory allocation
> library can have a pool of freed()ed memory for future use, the value
> can never shrink down.
> 

I've heard this before as well. It does not bear up using irb. I allocated
some 40Meg arrays (3 on my 160MB laptop) Each time, the machine would thrash
at the first allocation of the array then would perform smoothly when de-allocatincg
and re-allocating arrays. When all three arrays were allocated irb used 73% of 
my machine's memory resources, about 118 MB, when I ran a=b=c=nil; GC.start, irb's memory
usage went down to around 2 MB. Obviously ruby is somehow returning the memory to
the underlying OS. Is this Ruby, or irb or the OS itself that is allowing the OS
to reclaim the memory from irb? 


> -- 
> kjana / dm4lab.to                              December 20, 2001
> First come, first served.


-- 
Daniel P. Zepeda
daniel / zepeda-zone.net