Re: Newbie question on malloc()

[Micha Feigin <michf@post.tau.ac.il>]

On Thu, Jun 03, 2004 at 08:41:33AM +0100, Glynn Clements wrote:
> 
> John T. Williams wrote:
> 
> > > > As I understand it, that is entirely up to the operation system.  Linux
> > > > and NT Kernel systems do reclaim unfreed memory, however I believe one
> > > > the major problems with Win98 was that it did not.
> > > > 
> > > > Anyone with more information feel free to correct me
> > > 
> > > I very much doubt that the above is accurate.
> > > 
> > > It may be that Win98 had some specific memory leaks, but any OS which,
> > > in the general case, failed to recover a process' memory upon
> > > termination would run out of memory very quickly.
> > 
> > What you never had win98 crash on you after running for an hour? ;) 
> 
> Sure. I've also had it crash after running for less than a minute. And
> I've also had it run for hours without crashing.
> 
> However, if it didn't reclaim a process' memory upon termination, the
> scenario where you run a short-lived but memory-hungry program many
> times simply wouldn't be possible.
> 
> Bear in mind that many (possibly most) programs don't explicitly free
> dynamically-allocated memory blocks upon termination; they just
> terminate.
> 
> This is recommended practice. Explicitly freeing memory blocks is a
> waste of time: you're basically just modifying regions of the process'
> memory, which is about to be returned to the OS, whereupon its
> contents become irrelevant.
> 
> [It may also make the program substantially more complex, as you would
> need to keep track of such blocks.]
> 
> Note that free() doesn't generally return memory to the OS; it usually
> just records the fact that the specified region of memory is available
> for re-use by subsequent calls to malloc() etc.
> 

That would depend on the memory block size. Small memory blocks are
held as malloc allocates whole pages at a time, large memory blocks are
returned. Depending on size the OS may then also store them on caches
in case a memory block of the same size is requested again.

Otherwise in a long running program that allocates a lot of memory on
the start and then frees most of it would still be hogging all that
memory.

As for not freeing memory on program exit thats another issue since you
are saving malloc's internal work (which especially with large memory
chunks will probably mostly be a system call letting the kernel do most
of the work, for small chunks there is much more overhead).

> Similarly, malloc() doesn't necessary result in any additional memory
> being obtained from the OS; frequently it will just return a region of
> memory which has already been allocated to the process but isn't being
> used.
> 
> > May statement is based on something I remember vaguely from my OS class
> > 2 years ago, so I'm quite happy to believe I'm wrong.  I remember there
> > was some major issue with how win98 handled dynamic allocated memory,
> > but I can't exactly remember what.  
> 
> The main reason for the unreliability of Win95/98/ME is that, for
> compatibility with earlier versions, certain regions of memory are
> unprotected. So, if an application crashes, it can corrupt data
> belonging to other applications or the OS.
> 
> [The details relate to the fact that the 8086 doesn't have an MMU, so
> there is a single, global address space shared by all processes (and
> the OS). Originally, interprocess communication made extensive use of
> passing around handles to memory blocks, relying upon the fact that
> any process could read (and write) any part of memory. While Windows
> 3.1 and later require at least a 286, the behaviour was retained for
> compatibility.]
> 
> > After googling a little I seems that win95 had some problems with
> > Garbage Collection not win98.
> 
> The differences between 95 and 98 are essentially superficial. Win98
> includes IE, and probably a significant number of bug fixes, which may
> include bugs in memory allocation. However, the underlying
> architecture is unchanged, and that includes the way in which memory
> management works (other than any outright bugs which may have been
> fixed).
> 
> -- 
> Glynn Clements <glynn.clements@virgin.net>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>  
>  +++++++++++++++++++++++++++++++++++++++++++
>  This Mail Was Scanned By Mail-seCure System
>  at the Tel-Aviv University CC.
>