From: Kurt Stephens <ks@...>
Date: 2008-01-05T16:39:38+09:00
Subject: Re: Manual Memory Management

Gary Wright wrote:
> 
> On Jan 4, 2008, at 4:17 PM, Pramukta Kumar wrote:
>> the motivation for this was that I found myself in a situation where I
>> had to load up large objects from time to time within a long running
>> process but I only had to use each of them for a short period of
>> time.  the process normally doesn't need very much memory but during
>> those moments it does.
> 
> There is another hurdle to overcome.  While malloc() will
> request extra memory from the operating system as needed, in
> most implementations it will *never* return the favor and
> return unused memory back to the operating system.
> 
> So even if the garbage collector is 100% efficient, you'll
> be left will a chunk of memory that is free (as in can be
> used for new objects) but that the operating system still
> considers to be 'in use'.  The memory won't be returned to
> the OS until the process exits.
> 
> There are system calls that will allow a process to
> return memory to the OS but in general it isn't possible
> because of memory fragmentation.  In-use objects would
> have to be moved around to coalesce free memory into
> full pages to be released back to the OS.
> 

This is especially true if the allocator (malloc()) uses sbrk() rather
than mmap() to request pages.  The problem is worse the larger the
allocation requests from OS are, regardless of sbrk() or mmap().

Depending on allocation patterns, scavenging larger blocks from a free
list when memory pressure is high can sometime prevent fragmenting
bigger OS pages that maybe be allocated for smaller object sizes.

> A long running process could avoid this problem by
> forking off worker processes to deal with periodic tasks
> that require large amounts of memory.
> 
> Gary Wright
> 

Or use a copying-compacting collector; that could always return unused
memory to the OS. :)

Kurt Stephens
http://kurtstephens.com