Using shared libraries in an application

[H. Nicolaij]

We are investigating if it is usefull to
compile our COBOL application to .o files
and then linking them into a shared library.

Since we have quite a lot of objects the
shared libraries might be very huge.

When they all would be loaded at once when
starting the executable and only using some
of the code in the shared library, what does it do to the system memory / swap resources ?

What if 200 copies of the executable are
running at the same time ?

[Umapathy S]

hi,
Shared libraries are meant for this purpose only. You can load only one copy of shared library in the memory and all the executables which are linked with the shared library will use the same copy available in the memory.

If you have static libraries, then each executable will have a copy of the library in its memory consuming valuable system resources.

Hope I cleared your question,
Umapathy

[A. Clay Stephenson · Accepted solution]

This is good coding practice and should be used. Actually (unless you take very explicit steps to prevent it) the code is shared whether you use shared libraries (dynamically linked) or statically linked executables -- as long as more than one copy of the executable is running at the same time. The instructions (text) are always shared between processes but each has it's copy of data.

The advantage of using shared libraries is that the executable files are smaller; note that even if a shared library is 100MB only as much as is actually in use is loaded; if you are using one function from a shared library only that function will be loaded -- unless that function in turn depends upon other functions.

[Mike Stroyan]

A shared library will make little difference in size if it is used by only one program. Many copies of one program will share the text area. That is the code and constant global data.

Shared libraries are very effective at reducing the amount of disk space required for many executeables using the same library. They are not as helpful in reducing RAM and swap requirements. There is a tradeoff in the global data use with shared libraries. When a program uses a library like libc.sl, it will get a private data segment with all of the global data for all of libc. Most programs use only a small fraction of the functions in libc. Linking with an archive library can bring in only those .o files that are actually needed. So, the data area for a shared library can require more swap and RAM than the data use from an archive library.

RAM use for text and data of shared libraries can be a complicated matter. The text area is paged in from the shared library file as needed. It does not require any swap reservation because the library file is always there to page in from. The data area requires swap reservation. Both text and data areas do not require RAM until each page is referenced by a process. The text is system-wide, so different processes might cause different parts of a text area to page in. The data area is private to each process, so each process causes different pages to be brought into RAM. Shared libraries can cause the packing of data into pages to be less efficient than it is for archive libraries. Each page may contain a few things that are used and many things that are never used. Of course, that can happen with archive libraries as well. It is just more likely that a shared library will have unused code and data.

Shared libraries can also affect the efficiency of calls and data access. There is an extra level of indirection to make a call into a shared library or between visible functions in a shared library. Function addresses need to be looked up in a PLT table. Global data addresses need to be looked up in a DLT table.
That can add delay from extra memory accesses and from branch misprediction. The time to fill in the DLT and PLT tables can add time to process startup.

[Caesar_3]

Hello!

It's good in the end when you will work
with the library then it's in the memory
so the flow will be made faster.

Caesar