Electrical computers and digital processing systems: interprogra – Dynamic linking – late binding
Reexamination Certificate
1996-12-10
2004-07-27
Bullock, Jr., Lewis A. (Department: 2126)
Electrical computers and digital processing systems: interprogra
Dynamic linking, late binding
C717S163000, C717S128000, C717S127000
Reexamination Certificate
active
06769126
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates in general to information handling systems and more particularly to an apparatus and method for demand load analysis. Specifically, the present invention relates to an apparatus and method for selecting from a computer application program one or more dynamic link libraries (DLLs) to be demand loaded and for determining the benefit gained from demand loading a DLL or set of DLLs.
BACKGROUND OF THE INVENTION
A computer application program usually includes a number of separate routines. Typically, the routines include a main program and several subsidiary routines referred to as objects, modules, or resources. Execution of the application program begins with the main program with calls being made to the subsidiary routines. To operate as a complete program, prior to execution these routines are linked together using a linker such as 386 link. The linker copies each of the routines into an executable file for the application program. The linker also provides each of the routines with information identifying the locations of other routines so that the routines can access each other. The executable file can then be loaded into the memory of a computer such that the application program can be executed by the computer according to the instructions in the routines.
A dynamic link library (DLL) is an executable module or routine containing services that application programs can call to perform useful tasks, e.g., directory searches, login commands, searching functions, character string manipulations, etc. DLLs exist primarily to provide services to application programs. These libraries play an important role in operating systems such as Windows and OS/2, which use them to make their services and resources available to application programs.
DLLs are similar to run-time libraries. The main difference between DLLs and run-time libraries is that DLLs are linked with the application program at run time, that is, when the computer is executing the application program, not when the application program files are linked with the linker. Linking a library with an application program at run time is referred to as dynamic linking; linking a library with an application program by using the linker is referred to as static linking. The discussion below focuses on the OS/2 operating system (OS/2 is a trademark of International Business Machines Corporation), but those of ordinary skill in the art will understand that the following discussion applies equally to other operating systems, such as Windows, which utilize DLLs.
To access a DLL at run time, the application program must be able to obtain information indicating where to find the DLL. One method provided by operating systems utilizing DLLs is to use an import library, or reference library, which contains information regarding where to locate the DLL at run time. During linking, the linker uses statically linked reference libraries to resolve references to external services. As noted above, when an application program desires a service from a static link library, the linker copies the code for that service into the application program's executable file. When the application program desires a service run from a DLL, however, the linker does not copy any code from the DLL. Instead, the linker searches all defined import or reference libraries to find one that contains the necessary information regarding location of the DLL. The linker copies the necessary information from the reference or import library to create a dynamic link between the executing application program and the DLL.
When a process loads under the OS/2 operating system, all DLLs that the process references, either directly or indirectly, are also loaded. DLLs referencing other DLLs form a reference tree, the entire set of which gets loaded before the first instruction of the main program is executed. A typical DLL is only partially loaded. The remainder of the DLL is loaded on its first reference. The minimum DLL load requires some initialization in the operating system and the execution of the DLL's initialization routine. Any code or data referenced by the initialization routine, including the initialization routine itself, is loaded. For some DLLs, the dynamic link load time is quite expensive in terms of time, particularly if the DLL is very large or the DLL's initialization routine is very long.
The problem with load time initialization as described above is that frequently a process does not call the DLLs that it references. Therefore, the DLLs which are referenced but not called are unnecessarily loaded. When the load time of the unnecessary DLLs is a large percentage of the total execution time, the performance of the process degrades significantly.
There is a method utilized in the OS/2 operating system to prevent the unnecessary loading of DLLs. The method is called demand loading and is implemented using a well-known documented set of OS/2 operating system APIs (Application Program Interfaces). Demand loading is the process of delaying the load of a DLL until it is actually called. If a DLL is demand loaded but never demanded or called, it is effectively not loaded, and the cost of loading it is saved.
It will be appreciated that demand loading is utilized in other operating systems and creates problems similar to those encountered with the OS/2's demand loading technique.
The problem with the OS/2's demand loading technique is that it is difficult to use, particularly if a program has initially been written without it. It requires the programmer to replace a call to a target dynamic link with a load check, a couple of OS/2 demand loading APIs, and error recovery should the OS/2 APIs fail.
In U.S. patent application Ser. No. 08/742,103, U.S. Pat. No. 6,003,095, of common assignee herewith, an apparatus and method for automatically generating “demand loading code” necessary to implement an operating system's demand loading APIs is disclosed. The resulting code is packaged into a library which replaces a statically linked DLL reference library. In this manner, the called DLL is not changed in any way, but a tool is run against it to automatically generate a demand loading library for demand loading the DLL.
Performance analysis of a large software system with many DLLs can be very difficult. Many kinds of information are needed for the OS/2 operating system (OS/2 is a trademark of International Business Machines Corporation). A dekko hook/trace tool provides some, but not all, of the needed information. The dekko hook/trace tool provides timing information on both operating system events as well as user-written events. The dekko hook/trace tool searches the syntax of a C source file for the entry and exits of routines and automatically inserts dekko hooks. One of the problems with the dekko hook/trace tool, and the suite of utilities that thus far have been written for it, is a mechanism to easily and automatically apply dekko hooks to new code has not been provided.
Other non-dekko based performance tools have tried to solve the automatic and ease of use hooking problem, but each having been lacking in some respect. One particular problem is that prior art tools require some level of access to the source files used to build the executable of interest. Another problem is the processing overhead prior art tools introduce in the software being analyzed. For example, a dekko hook/trace tool requires access to source code so it can be temporarily modified and recompiled. The IBMCPP Performance Analysis Tool requires a recompile of the source code with a compiler switch indicating to enable tracing. IBMCPP Performance Analysis Tool is a tool which automatically hooks the entry and exits of routines and uses its own private trace log. MTrace is an instruction level trace tool which counts the number of instructions executed and accounts them to routine names. The MTrace tool does not require access to the source code but does require a symbol table generated when the executable of interest was built
Bullock, Jr. Lewis A.
International Business Machines - Corporation
LaBaw Jeffrey S.
Stepps, Jr. Charles D.
Yee Duke W.
LandOfFree
Apparatus and method for demand load analysis does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Apparatus and method for demand load analysis, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Apparatus and method for demand load analysis will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3232794