Minimize the library's data segment

As noted, only the text segment of a dynamically linked library is shared by all processes that use it; its data segment typically is not. Every process that uses a dynamically linked library usually gets a private memory copy of its entire data segment, regardless of how much data is needed. You can cut down the size of the data segment in several ways:

• Try to use automatic (stack) variables

• Don't use permanent storage if automatic variables will work

• Use functional interfaces rather than global variables

In some other implementations, system error messages are made available to applications only through two global variables:

   extern int	sys_nerr;
   extern char	*sys_errlist[];

1. The compilation system sets aside memory for the table in the address space of each executable that uses it, even though it does not know yet where the table will be loaded.

2. After the table is loaded, the dynamic linker copies it into the space that has been set aside.

3. Each process that uses the table gets a private copy of the library's data segment, including the table, and an additional copy of the table in its own data segment.

4. Each process pays a performance penalty for the overhead of copying the table at run time.

5. Because the space for the table is allocated when the executable is built, the application will not have enough room to hold any new messages you might want to add in the future. A functional interface overcomes these difficulties.

   static const char msg[] = {
   	"Error 0",
   	"Not owner",
   	"No such file or directory",
   	...
   };
   

   char 
   strerror(int err)
   {
   	if (err < 0 || err >= sizeof(msg)/sizeof(msg[0]))
   		return 0;
   	return (char )msg[err];
   }

In a similar way, try to allocate buffers dynamically -- at run time -- instead of defining them at link time. This saves memory because only the processes that need the buffers get them. It also allows the size of the buffers to change from one release of the library to the next without affecting compatibility as shown in the following:

   char 
   buffer()
   {
   	static char buf = 0;
   

   	if (buf == 0)
   	{
   		if ((buf = malloc(BUFSIZE)) == 0)
   			return 0;
   	}
   	...
   	return buf;
   }

• Exclude functions that use large amounts of global data if you cannot rewrite them in the ways described previously. If an infrequently used routine defines large amounts of static data, it probably does not belong in a dynamically linked library.

• Make the library self-contained. If a dynamically linked library imports definitions from another dynamically linked library, each process that uses it gets a private copy not only of its data segment, but of the data segment of the dynamically linked library from which the definitions were imported. In cases of conflict, this guideline should probably take precedence over the preceding one.