Re: [gtk-list] Re: O.S. memory usage
- From: Jeroen Benckhuijsen <jeroen benck demon nl>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Re: O.S. memory usage
- Date: Thu, 09 Mar 2000 21:34:54 +0100
I've also dealt with this problem on a sun solaris machine. Sun's answer
on this question (can't remember where i found it) : free memory is
wasted memory. In other words ,my bother to return the freed memory to
the OS, when changes are that the program will need to alloc memory
later on, and thus having to ask the OS for this memory again (speeds
things up). So giving the memory back to the OS is a waste of
processortime.
Jeroen
Sebastian Wilhelmi wrote:
>
> Hi Derek,
>
> > This is offtopic; my apologies. But it's a quickie, and I don't
> > know who else to ask (suggestions welcome!).
> >
> > If I write a program that does
> >
> > pointer = g_malloc(LOTS_OF_RAM);
> >
> > ...and then, later on, does
> >
> > g_free(pointer);
> >
> > Does that memory immediately go back to the O.S.? Will it be used
> > for drive caching, other apps, etc. as my program continues to run? Or
> > does Linux (and/or other O.S.s) hold on to it, say, in case my program
> > does another g_malloc or some such thing?
>
> malloc (as used by g_malloc) returns memory from the so called heap. This is a
> region in memory, that the allocation routines from libc take care of. It can
> be expanded in one direction. when there is no more space left for a new
> malloc, this region is expanded by a 'sbrk' system call (look at 'strace
> <program-name>'). memory, returned to libc by free is in general not returned
> to the system, but only appended to the list of free memory, which is
> consulted first, when new memory is requested. Some systems and libc's however
> support to give memory back to the OS. That is the case for Linux/glibc2.
> Other combinations might also do it. Memory can however only be returned to
> the system, if it is at the top of the heap.
>
> There are of course exceptions to the rule. glibc2 for example does have more
> than one heap (one for every thread + big allocations end up on their own
> heap), thus making it more complicated.
>
> Bye,
> Sebastian
> --
> Sebastian Wilhelmi | här ovanför alla molnen
> mailto:wilhelmi@ira.uka.de | är himmlen så förunderligt blå
> http://goethe.ira.uka.de/~wilhelmi |
>
> --
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]