Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Memory not freed? To:



Strictly speaking, when a fork occurs, the text and data segments are
doubly-addressed so that the same region of memory is used with both
addresses.  There is a small amount of overhead, but generally the amount
of memory consumed by multiple forked instances is the same as that
consumed by one instance.

When a write occurs so that a segment is modified, the operation is
trapped and the memory is copied out.  This is commonly known as a "copy
on write" technique.  The goal is to save memory consumption until it is
actually needed.  Only the data segments are affected, since text segments
cannot be written from inside their own contexts.

Linux also has a number of more finely controlled internal mechanisms
which allow greater efficiency, such as the "clone" technique.  On some
architectures, "copy on write" is applied to individual pages.

- -- Mike


On 2000-11-25 at 14:36 -0500, Jerry Feldman wrote:

> There have been several hacks in varuious Unix virtual memory managers to 
> speed up the loading of some executables, most specifically Unix commands, 
> mainly because commands are small and executed qucikly. The URL I posted 
> yesterday is a few years out of date, but provides a decent background. I 
> also suggest looking at the mmap(2) system call as well as fork and vfork. 
> When a program issues a fork(), logically, a duplicate is created, but in 
> reality, both the text and data segments are shared.
> 
> Greg Galperin wrote:
> 
> > Ad Jerry says, many virtual memory systems do this kind of thing (I'd
> > be surprised if Sun didn't, but I don't know for sure).

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org