Are shared libraries really loaded once

H

herbeyZepeda

Hi,

I understand that shared libraries(.so) are loaded once and reused by the processes that are loaded subsequently, thus eliminating the need to load the same library to memory each time a program runs.

However, so far I haven't found any source that actually verifies this for FreeBSD.

My understanding of the process is that rtld searches the .hints file produced by ldconfig to look for the required libraries. However, no where could I find whether rtld looks for a memory cached version of the library using some sort of mapping structure before reloading the .so.

The question is: if two processes use libTest.so, what is the maximum number of copies of libTest.so that will exist in memory at any point given the following sequence?

Process 1 is loaded
Process 1 requests an object in libTest.so, rtld loads libTest.so to memory
Process 2 is loaded
Process 2 requests an object in libTest.so, WHAT DOES RTLD DO?

-the design and implementation of the FreeBSD OS p.62 describes shared libraries in a process but my question was not answered

thanks
 
Keep in mind that each process runs in it's own memory map and cannot access memory used by other processes (not without shared memory at least). It's therefor logical that each process that uses a library will load this into it's own memory map.

The "shared" moniker means multiple applications can use the same library. It doesn't mean it shares that library once it's loaded.
 
Hi SirDice, that's what I thought. however, while reading about dynamically "linked" shared libraries, there are several sources (see below) that mention that sharing a library in RAM is possible in "most" operating systems. True, these sources do not address FreeBSD specifically, thus my inquiry in this forum.
Maybe they are referring to implementing this sort of library sharing by means of memory mapping as you mention?. In which case it becomes the programmer's responsibility to code accordingly rather than letting FreeBSD taking care of things by providing some parameters...



Some Sources:

http://en.wikipedia.org/wiki/Library_(computing)
"Programs can accomplish RAM sharing by using position independent code as in Unix, which leads to a complex but flexible architecture..."

http://www.network-theory.co.uk/docs/gccintro/gccintro_25.html

"...Most operating systems also provide a virtual memory mechanism which allows one copy of a shared library in physical memory to be used by all running programs, saving memory as well as disk space... "

thanks
 
Keep in mind that each process runs in its own memory map and cannot access memory used by other processes (not without shared memory at least). It's therefore logical that each process that uses a library will load this into its own memory map.

The "shared" moniker means multiple applications can use the same library. It doesn't mean it shares that library once it's loaded.
Click to expand...

The fact that two different processes have different memory maps and can't modify each other's memory doesn't mean that two copies of the library have been loaded. Executable pages being executable-only (at least, should not be writable), the same physical page can be used by two different processes.

Re the OP's question: rtld(1) uses mmap(2) to open shared libraries. It is my understanding, but do not quote me on that, that as a result, two copies of a given shared library opened by two processes will therefore be backed by the same physical pages. If one process writes to its executables pages (a very unusual thing to do) [resp. if the shared library is updated while the process is running, more likely)], COW techniques in the VM [resp. in the FS] system will make it so that only this process will see the modifications [resp. all running processes will continue using the old version].

I would love being corrected if I am incorrect.
 
Yes, there is some MMU trickery involved to physically load the library only once and map it to the memory map of different processes.
 
You must log in or register to reply here.
Back
Top