From: Benoit Cerrina <benoit.cerrina@...>
Date: 2001-12-23T03:55:57+09:00
Subject: [ruby-talk:29317] Re: memory management


"Daniel P. Zepeda" <daniel@zepeda-zone.net> wrote in message
news:20011221045652.5e3e2d3b.daniel@zepeda-zone.net...
> 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?

I believe the behaviour depends on the underlying malloc in the libc.  There
can be several different implementation for such and it is not directly the
OS that is responsible.
Benoit

>
>
> > --
> > kjana@dm4lab.to                              December 20, 2001
> > First come, first served.
>
>
> --
> Daniel P. Zepeda
> daniel@zepeda-zone.net
>