Memory not freed? To:

[Michael Bilow]

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).