Guidelines for building shared objects

This topic gives coding guidelines and maintenance tips for shared library development. Before getting down to specifics, we should emphasize that if you plan to develop a commercial shared library, you ought to consider providing a compatible archive as well. As noted previously, some users may not find a shared library appropriate for their applications. Others may want their applications to run on SCO OpenServer operating system releases without shared object support. Shared object code is completely compatible with archive library code. You can use the same source files to build archive and shared object versions of a library. Some of the reasons you might want to use shared objects are:

• Because library code is not copied into the executables that use it, they require less disk space.

• Because library code is shared at run time, the dynamic memory needs of systems are reduced.

• Because symbol resolution is put off until run time, shared objects can be updated without having to relink applications that depend on them.

• As long as its path name is not hard-coded in an executable, a shared object can be moved to a different directory without breaking an application.

To enhance shared library performance, you should:

1. Minimize the Library's Data Segment

2. Minimize Paging Activity.

Minimize the library's data segment.

As noted, only a shared object's text segment is shared by all processes that use it; its data segment typically is not. Every process that uses a shared object 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. Generally speaking, that will make library interfaces and code easier to maintain. Moreover, defining functional interfaces often eliminates global variables entirely, which in turn eliminates global copy data. The ANSI C function strerror(S) illustrates these points.

  In previous implementations, system error messages were made available to applications only through two global variables:

  extern int	sys_nerr;
  extern char	sys_errlist[];
  

  sys_errlist[X] gives a character string for the error X, if X is a nonnegative value less than sys_nerr. Now if the current list of messages were made available to applications only through a lookup table in an archive library, applications that used the table obviously would not be able to access new messages as they were added to the system unless they were relinked with the library. Errors might occur for which these applications could not produce useful diagnostics. Something similar happens when you use a global lookup table in a shared library:

  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.
  strerror might be implemented as follows:

  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 "Unknown error";
  	return (char )msg[err];
  }
  

  The message array is static, so no application space is allocated to hold a separate copy. Because no application copy exists, the dynamic linker does not waste time moving the table. New messages can be added, because only the library knows how many messages exist. Finally, note the use of the type qualifier const to identify data as read-only. Whereas writable data is stored in a shared object's data segment, read-only data is stored in its text segment. For more on const, see ``C language compilers''.

  In a similar way, you should try to allocate buffers dynamically -- at run time -- instead of defining them at link time. That will save memory because only the processes that need the buffers will get them. It will also allow the size of the buffers to change from one release of the library to the next without affecting compatibility as shown below:

  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 shared library.

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

Minimize paging activity.

Although processes that use shared libraries will not write to shared pages, they still may incur page faults. To the extent they do, their performance will degrade. You can minimize paging activity in the following ways:

• Organize to improve locality of reference.

  1. Exclude infrequently used routines on which the library itself does not depend. Traditional a.out files contain all the code they need at run time. So if a process calls a function, it may already be in memory because of its proximity to other text in the process. If the function is in a shared library, however, the surrounding library code may be unrelated to the calling process. Only rarely, for example, will any single executable use everything in the shared C library. If a shared library has unrelated functions, and if unrelated processes make random calls to those functions, locality of reference may be decreased, leading to more paging activity. The point is that functions used by only a few a.out files do not save much disk space by being in a shared library, and can degrade performance.

  2. Try to improve locality of reference by grouping dynamically related functions. If every call to funcA generates calls to funcB and funcC, try to put them in the same page. See ``Analyzing run-time behavior'' for a description of the fprof and fur tools that you can use to tune locality of reference.

• Align for paging. Try to arrange the shared library's object files so that frequently used functions do not unnecessarily cross page boundaries. First, determine where the page boundaries fall. You can use the nm(CP) command to determine how symbol values relate to page boundaries. After grouping related functions, break them up into page-sized chunks. Although some object files and functions are larger than a page, many are not. Then use the less frequently called functions as glue between the chunks. Because the glue between pages is referenced less frequently than the page contents, the probability of a page fault is decreased. You can put frequently used, unrelated functions together because they will probably be called randomly enough to keep the pages in memory.