Does dlopen create multiple library instances?

Question

I can't seem to find an answer after searching for this out on the net.

When I use dlopen the first time it seems to take longer than any time after that, including if I run it from multiple instances of a program.

Does dlopen load up the so into memory once and have the OS save it so that any following calls even from another instance of the program point to the same spot in memory?

So basically does 3 instances of a program running a library mean 3 instances of the same .so are loaded into memory, or is there only one instance in memory?

Thanks

Answer 1

Does dlopen load up the so into memory once and have the OS save it so that any following calls even from another instance of the program point to the same spot in memory?

Multiple calls to dlopen from within a single process are guaranteed to not load the library more than once. From the man page :

   If the same shared object is loaded again with dlopen(), the same
   object handle is returned.  The dynamic linker maintains reference
   counts for object handles, so a dynamically loaded shared object is
   not deallocated until dlclose() has been called on it as many times
   as dlopen() has succeeded on it.

When the first call to dlopen happens, the library is mmap ed into the calling process. There are usually at least two separate mmap calls: the .text and .rodata sections (which usually reside in a single RO segment) are mapped read-only, the .data and .bss sections are mapped read-write.

A subsequent dlopen from another process performs the same mmap s. However the OS does not have to load any of the read-only data from disk -- it merely increments reference counts on the pages already loaded for the first dlopen call. That is the sharing in "shared library".

So basically does 3 instances of a program running a library mean 3 instances of the same .so are loaded into memory, or is there only one instance in memory?

Depends on what you call an "instance".

Each process will have its own set of (dynamically allocated) runtime loader structures describing this library, and each set will contain an "instance" of the shared library (which can be loaded at different address in different process). Each process will also have its own instance of writable data (which uses copy-on-write semantics). But the read-only mappings will all occupy the same physical memory (though they can appear at different addresses in each of the processes).