How does a shared library work?
jeff at jgarrett.org
Tue Nov 1 11:39:41 UTC 2005
> > Every process has its own mapped memory. This memory is divided into
> > text segments (the actual code) and data segments (room for variables,
> > stack and other data that changes as you run the application). When you
> > use the shared library, its code is mapped into the processes memory.
> > Note that it's not copied - there's still only one "real" copy - but the
> > memory controller effectively makes it seem it's part of the rest of the
> > program code.
> Is the memory controller a part of the kernel?
No, it's hardware, very closely tied to the CPU. It's also known as the
MMU, or memory management unit. Broadly, one of its functions is to map
virtual pages in memory to physical pages. In the case of shared
libraries, what usually happens is that they get virtual memory
allocated to them, but they don't yet get loaded into physical memory.
When the program accesses the shared library the MMU issues a page fault
telling the CPU that the virtual address space doesn't correspond to
real physical memory yet. Then the kernel figures out that it's because
it hasn't loaded the shared library, and it loads the relevant portion
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the ubuntu-users