Hi, If the 'free' does not return the memory back to the OS, then what is the advantage of it. Will it not drain the memory in certain scenarios ? Why does free' of certain OS return the memory back to OS while others do not ? Thx in advans, Karthik Balaguru
free - The Memory is still not returned back to OS
Started by ●February 25, 2008
Reply by ●February 25, 20082008-02-25
>Hi, > >If the 'free' does not return the memory back to the OS, then what is >the advantage of it. Will it not drain the memory in certain >scenarios ? > >Why does free' of certain OS return the memory back to OS while others >do not ? > >Thx in advans, >Karthik Balaguru >If free does not return the memory to OS then look at the implementation of the free and ask the free,s developper.
Reply by ●February 25, 20082008-02-25
badal_akr wrote:>> Hi, >> >> If the 'free' does not return the memory back to the OS, then what is >> the advantage of it. Will it not drain the memory in certain >> scenarios ? >> >> Why does free' of certain OS return the memory back to OS while others >> do not ? >> >> Thx in advans, >> Karthik Balaguru >> > If free does not return the memory to OS then look at the implementation > of the free and ask the free,s developper."free" can be implemented in many ways, depending on the OS (if any) and the library. It is not uncommon for there to be a "cache" of heap between the application level and the operating system. Thus when the application asks for more memory (i.e., calls malloc() or a related library function), it may get memory from this cache without needing an OS call. If this cache does not have enough spare memory, the library function will ask the OS for more. When freeing memory, the application calls free() which returns the memory to the cache - the library functions will only return the memory to the OS when an entire block is unused (and it may not return it even then). Such a strategy can reduce fragmentation in the main memory, it can improve data locality, and it can allow the main OS memory manager and the library (or application-level memory manager) to have different allocation schemes. It is also quite possible to have free() do nothing - that's a valid strategy for embedded systems which might use malloc() for convenience during initialisation, but do not allocate and free memory during the application itself. Once we know what OS the O/P is talking about, and some more information about the particular usage, it might be possible to help.
Reply by ●February 25, 20082008-02-25
On Feb 25, 4:30=A0pm, David Brown <da...@westcontrol.removethisbit.com> wrote:> badal_akr wrote: > >> Hi, > > >> If the 'free' does not return the memory back to the OS, then what is > >> the advantage of it. Will it not drain the memory in certain > >> scenarios ? > > >> Why does free' of certain OS return the memory back to OS while others > >> do not ? > > >> Thx in advans, > >> Karthik Balaguru > > > If free does not return the memory to OS then look at the implementation=> > of the free and ask the free,s developper. > > "free" can be implemented in many ways, depending on the OS (if any) and > the library. =A0It is not uncommon for there to be a "cache" of heap > between the application level and the operating system. =A0Thus when the > application asks for more memory (i.e., calls malloc() or a related > library function), it may get memory from this cache without needing an > OS call. =A0If this cache does not have enough spare memory, the library > function will ask the OS for more. =A0When freeing memory, the application=> calls free() which returns the memory to the cache - the library > functions will only return the memory to the OS when an entire block is > unused (and it may not return it even then). =A0Such a strategy can reduce=> fragmentation in the main memory, it can improve data locality, and it > can allow the main OS memory manager and the library (or > application-level memory manager) to have different allocation schemes. > > It is also quite possible to have free() do nothing - that's a valid > strategy for embedded systems which might use malloc() for convenience > during initialisation, but do not allocate and free memory during the > application itself. > > Once we know what OS the O/P is talking about, and some more information > about the particular usage, it might be possible to help.I came across an info that claimed that free does not return the memory to the OS immediately and it returns at the end of the prorcess/ application. In the internet i found that some Memory Management techniques allow the immediate return of the freed memory to the OS and others allow only at the end of the application / process . So, i started to look for the reasons in the internet . I got some answers , but they were not very clear / conclusive, so i posted my query here. Thx, Karthik Balaguru
Reply by ●February 25, 20082008-02-25
karthikbalaguru wrote:> On Feb 25, 4:30 pm, David Brown <da...@westcontrol.removethisbit.com> > wrote: >> badal_akr wrote: >>>> Hi, >>>> If the 'free' does not return the memory back to the OS, then what is >>>> the advantage of it. Will it not drain the memory in certain >>>> scenarios ? >>>> Why does free' of certain OS return the memory back to OS while others >>>> do not ? >>>> Thx in advans, >>>> Karthik Balaguru >>> If free does not return the memory to OS then look at the implementation >>> of the free and ask the free,s developper. >> "free" can be implemented in many ways, depending on the OS (if any) and >> the library. It is not uncommon for there to be a "cache" of heap >> between the application level and the operating system. Thus when the >> application asks for more memory (i.e., calls malloc() or a related >> library function), it may get memory from this cache without needing an >> OS call. If this cache does not have enough spare memory, the library >> function will ask the OS for more. When freeing memory, the application >> calls free() which returns the memory to the cache - the library >> functions will only return the memory to the OS when an entire block is >> unused (and it may not return it even then). Such a strategy can reduce >> fragmentation in the main memory, it can improve data locality, and it >> can allow the main OS memory manager and the library (or >> application-level memory manager) to have different allocation schemes. >> >> It is also quite possible to have free() do nothing - that's a valid >> strategy for embedded systems which might use malloc() for convenience >> during initialisation, but do not allocate and free memory during the >> application itself. >> >> Once we know what OS the O/P is talking about, and some more information >> about the particular usage, it might be possible to help. > > I came across an info that claimed that free does not return the > memory to the OS immediately and it returns at the end of the prorcess/ > application.That depends on the OS, and the library used by the application - again, you'll get little useful information until you tell us what OS and tools you are using.> In the internet i found that some Memory Management techniques allow > the immediate return of the freed memory to the OS and others allow > only at the end of the application / process .Both are perfectly valid techniques, but are appropriate for different sorts of systems. It is the library used by the application that decides which method is used.> So, i started to look for the reasons in the internet . I got some > answers , but > they were not very clear / conclusive, so i posted my query here. >Your posts are not clear either - we don't know what tools you are using, or where you have found this information on the web. We also don't know what you have tried for yourself. Have you looked at the documentation and the source for your application, your library, and your OS?
Reply by ●February 25, 20082008-02-25
On Feb 25, 6:41=A0pm, David Brown <da...@westcontrol.removethisbit.com> wrote:> karthikbalaguru wrote: > > On Feb 25, 4:30 pm, David Brown <da...@westcontrol.removethisbit.com> > > wrote: > >> badal_akr wrote: > >>>> Hi, > >>>> If the 'free' does not return the memory back to the OS, then what is=> >>>> the advantage of it. Will it not drain the memory in certain > >>>> scenarios ? > >>>> Why does free' of certain OS return the memory back to OS while other=s> >>>> do not ? > >>>> Thx in advans, > >>>> Karthik Balaguru > >>> If free does not return the memory to OS then look at the implementati=on> >>> of the free and ask the free,s developper. > >> "free" can be implemented in many ways, depending on the OS (if any) an=d> >> the library. =A0It is not uncommon for there to be a "cache" of heap > >> between the application level and the operating system. =A0Thus when th=e> >> application asks for more memory (i.e., calls malloc() or a related > >> library function), it may get memory from this cache without needing an=> >> OS call. =A0If this cache does not have enough spare memory, the librar=y> >> function will ask the OS for more. =A0When freeing memory, the applicat=ion> >> calls free() which returns the memory to the cache - the library > >> functions will only return the memory to the OS when an entire block is=> >> unused (and it may not return it even then). =A0Such a strategy can red=uce> >> fragmentation in the main memory, it can improve data locality, and it > >> can allow the main OS memory manager and the library (or > >> application-level memory manager) to have different allocation schemes.=> > >> It is also quite possible to have free() do nothing - that's a valid > >> strategy for embedded systems which might use malloc() for convenience > >> during initialisation, but do not allocate and free memory during the > >> application itself. > > >> Once we know what OS the O/P is talking about, and some more informatio=n> >> about the particular usage, it might be possible to help. > > > I came across an info that claimed that free does not return the > > memory to the OS immediately and it returns at the end of the prorcess/ > > application. > > That depends on the OS, and the library used by the application - again, > you'll get little useful information until you tell us what OS and tools > you are using. > > > In the internet i found that some Memory Management techniques allow > > the immediate return of the freed memory to the OS and others allow > > only at the end of the application / process . > > Both are perfectly valid techniques, but are appropriate for different > sorts of systems. =A0It is the library used by the application that > decides which method is used. > > > So, i started to look for the reasons in the internet . I got some > > answers , but > > they were not very clear / conclusive, so i posted my query here. > > Your posts are not clear either - we don't know what tools you are > using, or where you have found this information on the web. =A0We also > don't know what you have tried for yourself. =A0Have you looked at the > documentation and the source for your application, your library, and > your OS?-This is a generic query. It is not with respect to any particular OS / Tool. I am just seeking for clarification of some info that i came across. Karthik Balaguru
Reply by ●February 25, 20082008-02-25
On Mon, 25 Feb 2008 12:30:20 +0100, David Brown <david@westcontrol.removethisbit.com> wrote:>"free" can be implemented in many ways, depending on the OS (if any) and >the library. It is not uncommon for there to be a "cache" of heap >between the application level and the operating system. Thus when the >application asks for more memory (i.e., calls malloc() or a related >library function), it may get memory from this cache without needing an >OS call. If this cache does not have enough spare memory, the library >function will ask the OS for more. When freeing memory, the application >calls free() which returns the memory to the cache - the library >functions will only return the memory to the OS when an entire block is >unused (and it may not return it even then). Such a strategy can reduce >fragmentation in the main memory, it can improve data locality, and it >can allow the main OS memory manager and the library (or >application-level memory manager) to have different allocation schemes.A typical example would be an OS with virtual memory. If malloc does not have a sufficiently free space in the cache, it will ask the OS for a number virtual memory pages. The amount of virtual memory must be a multiple of the page size (4 KiB for x86). When free() is called, it will return the memory into the cache, but this is not usually returned to the OS, until the program terminates. One reason for this is that while most small allocations within a virtual memory page have been freed by free(), there may still be other active allocations on that virtual memory page, preventing any attempts to return the page to the OS. Paul
Reply by ●February 25, 20082008-02-25
karthikbalaguru wrote:> Hi, > > If the 'free' does not return the memory back to the OS, then what is > the advantage of it. Will it not drain the memory in certain > scenarios ? > > Why does free' of certain OS return the memory back to OS while others > do not ?The local heaps without deallocation is a fairly common trick supported by many compilers and OS environments. It is fast and it simplifies the memory management immensely. When you don't need the dynamic memory any longer, you just kill the whole heap. Alternatively, the heap will be released automatically when the task exits. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●February 25, 20082008-02-25
On Sun, 24 Feb 2008 23:16:19 -0800 (PST), karthikbalaguru wrote:> Hi, > > If the 'free' does not return the memory back to the OS, then what is > the advantage of it. Will it not drain the memory in certain > scenarios ? > > Why does free' of certain OS return the memory back to OS while others > do not ?While this seems pretty off topic, the reason has nothing to do with the OS. "free" is a C runtime library function, not an OS function. Most C runtime libraries use "heaps" or private blocks of memory they manage. When you free memory from the heap, the runtime keeps that memory around in many cases to re-use for the next malloc call. This is a performance issue.
Reply by ●February 25, 20082008-02-25
karthikbalaguru wrote:> > If the 'free' does not return the memory back to the OS, then what > is the advantage of it. Will it not drain the memory in certain > scenarios ? > > Why does free' of certain OS return the memory back to OS while > others do not ?The following is the C standard description of free. Note the phrase "made available for further allocation". It says nothing about the OS, so that "further allocation" may be limited to the process that executed the free function. If you want to see the code for an actual malloc/free application, you can read nmalloc.zip, which is intended for DJGPP, but will probably function unchanged on most Linux, Dos, or Windows environments. See: <http://cbfalconer.home.att.net/download/> 7.20.3.2 The free function Synopsis [#1] #include <stdlib.h> void free(void *ptr); Description [#2] The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation. If ptr is a null pointer, no action occurs. Otherwise, if the argument does not match a pointer earlier returned by the calloc, malloc, or realloc function, or if the space has been deallocated by a call to free or realloc, the behavior is undefined. Returns [#3] The free function returns no value. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section. -- Posted via a free Usenet account from http://www.teranews.com
