Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2000-02-14
2003-12-02
Breene, John (Department: 2177)
Data processing: database and file management or data structures
Database design
Data structure types
C714S038110, C717S126000, C717S140000
Reexamination Certificate
active
06658421
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
This invention relates to the implementation of object oriented languages that are statically compiled into platform-specific object code. More specifically, it involves detecting when changes to a class require clients of that class to be recompiled due to compiled-in assumptions about the changed class that the compiler has generated in the object code for the client classes.
2. Prior Art
Object oriented languages include the C++ and Sun Microsystems, Inc.'s Java programming languages. Java has been generally available on most widely used general computing systems since about 1996. It was originally intended for use as an interpreted language which could be used to program World Wide Web browsers. Lately, it has been gaining acceptance as a programming language for server applications. In this domain, performance of the application is critical. This motivates the need for optimizing static compilers that take Java source or bytecodes and generate highly optimized, platform-specific object code. The IBM® Visual Age® for Java High Performance Compiler (HPC) is such a compiler.
Typically, with respect to time, compile time is followed by execution time (which is also referred to as run time). Execution, or run, time includes load, initialize, execute and terminate times or processes. A programmer typically codes in source code, to produce a plurality of .c or .java files. During compile time, a compiler compiles these into object code files which are then linked into executable files in an application or library. Typically, many object files are linked into a much smaller number of executable files, referred to as a dynamically loaded library (DLL).
The problem addressed by the invention occurs when a programmer goes through the typical processes of editing, compiling, debugging, changing, and recompiling. Because of the large number of source files involved, it is desired to recompile only those source files which are changed, to regenerate only the object file corresponding to that changed source file. However, it is also the case that during compilation of one source file, the compiler makes assumptions about other source files to which the one source file refers. If, by virtue of the recompilation of the new source file, the assumptions in old source files are no longer valid, a release-to-release-binary incompatibility results.
Release-to-release binary compatibility (RRBC) in object oriented languages refers to the ability to modify a class without having to recompile all of the other classes in the application that refer to this class.
Compilers for statically compiled object oriented languages such as C++ embed assumptions about the layout of compiler-generated data structures for the referent classes in the compiled code of each class. These assumptions usually refer to the layout of fields in instances of the referent classes and the method tables of the referent classes. In general, the assumptions involve the particular indices of fields and methods within these structures. Since the assumptions are all made by the compiler, the user usually has no idea which classes need recompilation when a particular class has been modified, or in the case of object libraries, what those classes may even be.
Release-to-release binary compatibility has been implemented for statically compiled object oriented languages by developing object run time systems such as System Object Model (SOM). These run time systems specify the object models for which the compiler must generate code. RRBC is usually provided by adding an extra level of indirection into method dispatch and field access code generation. Typically, a compiler-generated static temporary is created (that is, has storage allocated) to hold the appropriate offset or table index, which is initialized by the object run time system to the appropriate value. Since method dispatch and field access tend to be frequent operations in object oriented programs, such an implementation imposes a considerable performance penalty on the application.
U.S. Pat. No. 5,339,438 (Conner et al.) for Version Independence for Object Oriented Programs describes a method for implementing RRBC in IBM's System Object Model (SOM). SOM involves using static temporaries initialized at application load time to hold the offsets or sizes that may change from version to version of a referent class. By adding an extra level of indirection to instance field references and instance method invocation, SOM implements RRBC. Introducing an extra level of indirection to implement full RRBC comes at a significant performance cost, and there is a need in the art for a high performance method for detecting RRBC violations without user intervention.
Another contemporary approach provides a technique for detecting whether a particular release of an operating system can correctly execute a program that is built with a higher (later) release of the same operating system (this is called downward compatibility). Each program contains a compatibility level indicator. The value of the indicator is determined by the compiler that generates the object code of the program by determining which instructions are used by the program. Any instruction is supported in a particular release and all subsequent releases of the operating system. The highest such release number among all instructions used by the program is the compatibility level indicator for the program. When the operating system loads the program for execution, it will only execute the program if the compatibility level indicator is less than or equal to its own release level. This method assumes a linear progression of compatibility. That is, a compatibility level of N implies that the program can be executed on all operating system release levels greater than or equal to N, and on no operating system level less than N. There is a need in the art for a solution to the problem of changing field and method tables in which this property (linear progression of compatibility) does not necessarily hold. Furthermore, there is a need for a method which allows for the separation of aspects of compatibility (i.e., if the field tables of a class change but the method tables do not, then only those client classes which require access to the field tables of the class will fail a run time signature check-that is, a check at run time initialization of a signature generated at compile time).
U.S. Pat. No. 5,768,588 (Endicott, et al.) for Efficient Method Router That Supports Multiple Simultaneous Object Versions describes the implementation of the New Object Model (NOM), which is the underlying object data structures and run time support that can be used to implement object oriented languages such as Smalltalk and C++, in particular, in an interactive environment. Objects in NOM contain a pointer to an interface table. The interface table contains a number of tuples, one for each class in the inheritance hierarchy for the class of the object. Each tuple contains a class signature to identify the class at that level in the hierarchy, and a pointer to a method table for methods of that class. A method invocation contains an object identifier, a level number, a call signature and a method table offset. The object identifier is dereferenced to obtain the interface table for the object, and the level is used as the index into this table. The call signature is checked against the class signature in the tuple found at this entry in the interface table. If they do not match, the program is aborted. If they do match, the method pointer is obtained by indexing the method table pointed to by this tuple with the method table offset in the call. Since NOM implements full RRBC (like SOM), the call signature is not used to detect RRBC violations. Instead it is used to check that the class hierarchy of the callee did not change from the time that the call was compiled (i.e., the class that is assumed to be at a particular level in the inheritance tree of the callee i
Breene John
Lewis Cheryl
Ludwin, Esq. Richard M.
Scully Scott Murphy & Presser
LandOfFree
System and method for detecting release-to-release binary... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for detecting release-to-release binary..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for detecting release-to-release binary... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3125194