3

When an executable links with a static library, the executable contains only the necessary library parts, that are used in the code, right?

But I'm missing the part with - how the shared objects (the dynamic linked libraries) are used exactly?

As far as I know, they are not included in the executable, they are dynamically loaded using dlopen and this is done directly by the linker, right?

In this case, where's this library located in the memory? I mean, there are posts here, explaining that the dynamic libraries could reduce the memory usage, but how exactly? And if a dynamic library is somehow loaded into a shared memory (for several processes), how the kernel handles the concurrency in this case?

I realize this is something probably fundamental and sorry if this is a duplicate, I couldn't find such.
I am aware of Static linking vs dynamic linking and what I ask is a bit different.

Community
  • 1
  • 1
Kiril Kirov
  • 37,467
  • 22
  • 115
  • 187
  • this will help hopefully[MSDN](http://msdn.microsoft.com/en-us/library/windows/desktop/ms682589%28v=vs.85%29.aspx). maybe read [this](http://msdn.microsoft.com/en-us/library/windows/desktop/ms681914%28v=vs.85%29.aspx) too – Koushik Shetty Apr 05 '13 at 10:51
  • Library parts is a bit vague. A library is composed of named sections, and in the case of a static library a linker can prune entire sections if they are unused, however it cannot prune some unused functions *within* a section that is not entirely unused. – Matthieu M. Apr 05 '13 at 12:09

2 Answers2

8

The shared library is indeed loaded into memory that is shared between all "users" (all applications using the same library).

This is essentially done by reference-counting, so for each new user of the library, the reference is counted up. When an application exits, the reference count is counted down. If it gets to zero, the library is no longer needed, and will be removed from memory (quite possibly only when "memory is needed for something else", rather than "immediately"). The reference counting is done "atomically" by the kernel, so there is no conflict of concurrency.

Note that it's only the CODE in the shared library that is actually shared. Any data sections will be private per process.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • 2
    Hmm, yep. I think that's what I was missing - sharing only code and not data. I feel kinda stupid right now :) – Kiril Kirov Apr 05 '13 at 10:58
  • Okay, having said this, do you think, that the memory usage will be the same for both cases: a single app, statically linked with a lib and the same app, but dynamically linked with the same lib? I'm talking about the case, when there's only one instance (only one process) that uses the lib. – Kiril Kirov Apr 05 '13 at 11:04
  • 1
    Actually, that's hard to say, as it ALSO depends on what parts of the actual app is being used. At least in Linux, all executable code is "demand loaded", meaning that a page of memory in an executable or shared library is only loaded from disk once it is needed. This applies in both cases, and it really depends on "how it is being used". I suspect it's "half a dozen of one, and six of the other" - in other words, not a lot of difference. – Mats Petersson Apr 05 '13 at 11:07
  • @Mats Petersson, for data section will kernel use copy on write mechanisms to further optimize? – Abhijit-K Apr 05 '13 at 11:18
  • The kernel MAY use copy-on-write in some circumstances, yes. – Mats Petersson Apr 05 '13 at 11:19
0

the dynamic library is loaded only once for all the processes that are using them. The memory of the dynamic library is then mapped into the process adress space by the operating system. This way, it consumes its required memory only once. With static linking, all executables include the statically linked code. When the executable is loaded, the statically linked code is loaded as well. This means, a function that is included in 10 executables resides 10 times in memory.

Tobias Langner
  • 10,634
  • 6
  • 46
  • 76