A model for HP-UX shared libraries using shared memory on HP Precision Architecture computers - Hewlett-Packard's UNIX-like operating system

Hewlett-Packard Journal, Oct, 1989 by Anastasia M. Martelli

A Model for HP-UX Shared Libraries Using Shared Memory on HP Precision Architecture Computers

CURRENTLY, WHEN AN HP-UX USER PROGRAM includes calls to a library, a copy of the library code is added to the executable file at link time. This means that each executable file that uses a routine has a copy of that routine on disk and in memory when it is running. This type of library technology is called archived libraries (Fig. 1a).

Shared libraries allow multiple processes to share a single copy of library code. This is accomplished by loading shared library code into the system separately from any one program. When a program calls a routine in the shared library, it branches into and out of the shared library at run time (Fig. 1b). Thus an executable file that uses shared libraries does not hold library and initialized data. This results in smaller files and lower disk space requirements. Memory use may be reduced because only one copy of the library routines exists in memory.

After investigation, the HP-UX product team proposed that shared libraries not be supported for Release 2.0. However, the PORT/HP-UX project was receiving strong user feedback to reduce the size of executable program files that use their emulation library. (*1) Therefore, a solution had to be provided. This paper describes a model that was designed and implemented to help meet this customer need. No kernel support was necessary, but minor changes were made to the linker.

Goals of the Implementation

Besides supplying the functionality required by the PORT/HP-UX product, there were two major design goals. The first was to avoid modification of the HP-UX core product, that is, the kernel, compilers, and linker, to support this model of shared libraries. The second was to avoid hard-coding the shared library text and data addresses. Hard-coding the addresses requires the user process to attach shared library code and data at predetermined addresses within their virtual address space, which is a wellknown problem with some other UNIX (*2) implementations of shared libraries.

Mapping the Shared Library

The design of the shared library began with the decision of where in the process's address space the shared library would reside. A shared library consists of two parts: the text (or code) and the data. Although there is only one copy of the text for all processes that attach to the shared library, each process must have its own private copy of the data. Therefore, the text and data must be handled separately.

Consider the HP-UX use of a process's address space on the HP 9000 Series 800 (Fig. 2). The addres space of process is divided into four areas. The first area is used for the text of the process. When there are multiple instances of the same program running, this text is shared across all instances, but the user process may not write to this area. The second quadrant is used for process private data, heap, and stack. The user process can write to this data area and it can be dynamically expanded to a system-imposed limit. The kernel stack resides in the third area. This is the stack information of the process while it is executing in the kernel and the process is not allowed to write on it. The fourth area is used for things that may need to be accessible to all processes on the system. Besides some miscellaneous kernel information, this area includes shared memory segments created by the user processes. The user can write to this area by creating and attaching a shared memory segment.

At first glance, it may seem that the first area, which contains sharable text, would be a good place to put the shared library text. This is not the case, for two reasons. First, the user cannot place text in this area of the user process space except through the exec system call, which completely overlays what is already there; thus, the shared library text would be there, but the user code would have disappeared. Second, for architectural reasons the area that contains the shared library must be the same for all processes; thus, the user would have to keep track of two areas with the same short address--the one containing user text and the one containing the shared library text. Besides being very complex, this would also degrade performance.

The only other area of the process's address space that a user shares with other processes is the fourth area. The user can set up a shared memory segment and any other process can attach to it as long as the proper key is provided. A shared library can be set up in a shared memory segment with a well-known key.

Unlike text, each process has its own private copy of shared library data. Since a single set of shared library instructions must be able to access data areas attached to multiple processes, some implementations have had to reserve specific portion of a process's virtual address space for shared library data areas, and the data of the shared library must be mapped to the same virtual address in each process that uses it. Additionally, that virtual address must be decided upon when the shared library is built.