US8689200B1 - Method and system for optimizing an executable program by generating special operations for identical program entities - Google Patents

Method and system for optimizing an executable program by generating special operations for identical program entities Download PDF

Info

Publication number
US8689200B1
US8689200B1 US13/005,394 US201113005394A US8689200B1 US 8689200 B1 US8689200 B1 US 8689200B1 US 201113005394 A US201113005394 A US 201113005394A US 8689200 B1 US8689200 B1 US 8689200B1
Authority
US
United States
Prior art keywords
object code
program entity
program
address
code segment
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related, expires
Application number
US13/005,394
Inventor
Sriraman Tallam
Ian Lance Taylor
Cary Coutant
Xinliang David Li
Christopher Demetriou
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Google LLC
Original Assignee
Google LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Google LLC filed Critical Google LLC
Priority to US13/005,394 priority Critical patent/US8689200B1/en
Assigned to GOOGLE INC. reassignment GOOGLE INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: COUTANT, CARY, DEMETRIOU, CHRISTOPHER G., LI, XINLIANG DAVID, TALLAM, SRIRAMAN, TAYLOR, IAN LANCE
Application granted granted Critical
Publication of US8689200B1 publication Critical patent/US8689200B1/en
Assigned to GOOGLE LLC reassignment GOOGLE LLC CHANGE OF NAME Assignors: GOOGLE INC.
Expired - Fee Related legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/44—Encoding
    • G06F8/443—Optimisation
    • G06F8/4434—Reducing the memory space required by the program code
    • G06F8/4435—Detection or removal of dead or redundant code

Definitions

  • the disclosed embodiments relate generally to program compilation and linking, and in particular, to a system and method for optimizing an executable program by merging identical program entities such as functions or read-only data members in the executable program.
  • a method for optimizing the object code of a program using a computer includes: receiving one or more object code units associated with an executable program; identifying, among the one or more object code units, a first program entity and a first set of operations associated with the first program entity and a second program entity and a second set of operations associated with the second program entity, wherein each program entity has an object code segment and an associated address; updating the one or more object code units by causing the second set of operations to be associated with the first program entity if the first program entity's object code segment is identical to the second program entity's object code segment and no operation from the second set operates on the address of the second program entity; and combining the updated one or more object code units into the executable program.
  • a system for optimizing an executable program includes one or more central processing units for executing programs; and memory to store data and to store one or more programs to be executed by the one or more central processing units.
  • the one or more programs include instructions for: receiving one or more object code units associated with an executable program; identifying, among the one or more object code units, a first program entity and a first set of operations associated with the first program entity and a second program entity and a second set of operations associated with the second program entity, wherein each program entity has an object code segment and an associated address; updating the one or more object code units by causing the second set of operations to be associated with the first program entity if the first program entity's object code segment is identical to the second program entity's object code segment and no operation from the second set operates on the address of the second program entity; and combining the updated one or more object code units into the executable program.
  • a computer readable-storage medium stores one or more programs for execution by one or more processors of a computer system.
  • the one or more programs include instructions for: receiving one or more object code units associated with an executable program; identifying, among the one or more object code units, a first program entity and a first set of operations associated with the first program entity and a second program entity and a second set of operations associated with the second program entity, wherein each program entity has an object code segment and an associated address; updating the one or more object code units by causing the second set of operations to be associated with the first program entity if the first program entity's object code segment is identical to the second program entity's object code segment and no operation from the second set operates on the address of the second program entity; and combining the updated one or more object code units into the executable program.
  • a method for optimizing the object code of a program using a computer includes: receiving one or more object code units associated with an executable program; identifying, among the one or more object code units, a first program entity and a first set of operations associated with the first program entity and a second program entity and a second set of operations associated with the second program entity, wherein each program entity has an object code segment and an associated address; updating the one or more object code units by inserting a predefined instruction before the first program entity's object code segment and causing the second set of operations to be associated with the predefined instruction if the first program entity's object code segment is identical to the second program entity's object code segment; and combining the updated one or more object code units into the executable program.
  • a system for optimizing an executable program includes one or more central processing units for executing programs; and memory to store data and to store one or more programs to be executed by the one or more central processing units.
  • the one or more programs include instructions for: receiving one or more object code units associated with an executable program; identifying, among the one or more object code units, a first program entity and a first set of operations associated with the first program entity and a second program entity and a second set of operations associated with the second program entity, wherein each program entity has an object code segment and an associated address; updating the one or more object code units by inserting a predefined instruction before the first program entity's object code segment and causing the second set of operations to be associated with the predefined instruction if the first program entity's object code segment is identical to the second program entity's object code segment; and combining the updated one or more object code units into the executable program.
  • a computer readable-storage medium stores one or more programs for execution by one or more processors of a computer system.
  • the one or more programs include instructions for: receiving one or more object code units associated with an executable program; identifying, among the one or more object code units, a first program entity and a first set of operations associated with the first program entity and a second program entity and a second set of operations associated with the second program entity, wherein each program entity has an object code segment and an associated address; updating the one or more object code units by inserting a predefined instruction before the first program entity's object code segment and causing the second set of operations to be associated with the predefined instruction if the first program entity's object code segment is identical to the second program entity's object code segment; and combining the updated one or more object code units into the executable program.
  • FIG. 1A is an overview block diagram of a process for transforming source codes of a program into an executable program in accordance with some embodiments.
  • FIGS. 1B and 1C illustrate an example of merging identical functions in an executable program in accordance with some embodiments.
  • FIG. 2 is a flow chart of a process for merging identical functions in connection with a linking progress in accordance with some embodiments.
  • FIG. 3A is a block diagram of a relocation data structure in accordance with some embodiments.
  • FIG. 3B is a block diagram of a hash data structure in accordance with some embodiments.
  • FIGS. 4A and 4B are flow charts of a process for optimizing an executable program in accordance with some embodiments.
  • FIG. 5 is a block diagram of a system for code optimization in accordance with some embodiments.
  • FIG. 1A is an overview block diagram of a process for transforming the source code of a program into an executable program in accordance with some embodiments.
  • the program's source code is stored within one or more source code files 100 - 1 to 100 -M.
  • a compiler 110 transforms the source code files into one or more object code files 120 - 1 to 120 -N. Depending on the size of the executable program, the number of object code files ranges from a few to hundreds or even thousands.
  • the compiler 110 may include other components such as an assembler.
  • the process of compiling a program from a human-readable format such as source code into the binary format that a processor executes involves successively transforming the source code into simpler forms and discarding redundant information at each step until the result is a sequence of simple operations, register names, memory addresses, and binary values that the processor can understand.
  • instructions within one source code file may be distributed over multiple object code files and instructions within multiple source code files may be merged into a single object code file.
  • the linker 130 is a program that combines the one or more object files 120 - 1 to 120 -N generated by the compiler 110 into a single binary executable program 140 , which can be executed on a specific computer platform.
  • an executable program may be generated by combining a large number of object code files. Many of these object code files may have identical code segments such as identical functions or read-only data members. Note that although identical source code segments may result in an identical object code segment, different source code segments may still be associated with an identical object code segment if the source code differences are “ignored” by the compiler 110 .
  • FIG. 1B illustrates an exemplary program that has two source code files, “A.cc” 150 and “B.cc” 155 .
  • the source code file 150 includes a definition of a function Fn1( ) and the source code file 155 includes a definition of another function Fn2( ).
  • the two functions are not identical at the source code level, their object code counterparts are identical.
  • the source code file 150 includes a main( )function that has at least two function calls, one call of Fn1( ) 160 and another call of Fn2( ) 165 .
  • each of the two source code files 150 and 155 is compiled into a separate object code file “A.o” 170 or “B.o” 175 .
  • the compiler 110 assumes that every function in a source code file is different from another function in the same source code file or another source file and therefore assigns a unique address to each function in the object code. In this example, it is assumed that the address of the function Fn1( ) in the object code file 170 is 0xa123 and the address of the function Fn2( ) in the object code file 175 is 0xa134.
  • the binary executable 180 generated by the linker 130 in accordance with the two object code files will have two copies of identical binary functions, one for the function Fn1( ) and the other one for the function Fn2( ).
  • FIG. 1C illustrates an example of merging identical functions in an executable program in accordance with some embodiments.
  • the process of merging identical functions into a single copy is referred to as “code folding.”
  • the symbol table before the code folding has two entries associated with the two symbols Fn1 and Fn2. These two symbols represent two different functions in the source code and are associated with two different addresses 0xa123 and 0xa134, each address corresponding to a respective function in the source code. Because the two functions are identical at the object code level, it is possible to update the symbol table by merging the two functions into one copy.
  • FIG. 2 is a flow chart of a process for merging identical functions in connection with a linking progress in accordance with some embodiments. As will be explained below, this process sums up at least four different embodiments of performing code folding, each embodiment providing a unique aspects for merging identical functions.
  • the code folding process 240 is an auxiliary process associated with the main linking process 200 .
  • the main linking process 200 chooses to optimize the object code by merging identical functions or read-only data members, the code folding process 240 is initiated, e.g., via a different thread.
  • the main linking process 200 begins with reading ( 210 ) the symbols, relocations, and objects associated with an executable program. Note that a relocation data structure is a well-known entity used in the art of program compiling and linking.
  • the compiler 110 For each reference (or call) to a function or its corresponding address in the executable program, the compiler 110 generates a relocation entry at the compilation time and stores the relocation entry within a data structure as part of the object code.
  • a relocation entry has an attribute that can be used to determine whether a reference is associated with a function or its address.
  • FIG. 3A is a block diagram of a relocation data structure in accordance with some embodiments.
  • the relocation data structure 300 includes multiple attributes for generating the executables by the linker 130 such as relocation type 310 , relocation symbol name 320 , and relocation symbol value 330 .
  • the relocation type 310 is an attribute that depends on: (i) the architecture of the target processor for which the executable is generated, (ii) the type of machine instruction code constituting the executable, and (iii) whether the relocation is associated with a reference to a function or a reference to a function address.
  • the relocation types 310 are commonly represented using standard names or designations, some examples of which are shown in the table below.
  • This table shows the relocation type names associated with combinations of different executable object types (e.g., position-independent executable (PIE) objects and position-independent code (PIC) objects) and different relocation reference types, all for target processors that are compatible with an i386 instruction set architecture.
  • PIE position-independent executable
  • PIC position-independent code
  • this property can be used to identify those operations on a function's address that may cause unsafe behavior if the function were merged with another identical function.
  • relocation type as an indicator or proxy to determine whether two identical functions can be merged is merely one embodiment of the present application.
  • another property found in the object code may be used for similar purpose as long as the property demonstrates differences between a reference to a function and a reference to a function address.
  • such property may be derived from one or more attributes associated with the relocation or other information.
  • the fact that a function is subject to an operation on its address (e.g., the function's relocation type is R — 386_GOTOFF) only means that there is a potential risk of merging such function into another identical function but it does not necessarily guarantee that such merge would result in unsafe behavior. For example, if the operation does not compare the function's address with another function's address as illustrated above, it is still possible to merge the function with another identical one. In some embodiments, if only one of two identical functions has operations on its address while the other one does not, it is safe to merge the other one into the first one such that there is no operation on a substituting function address.
  • the function's relocation type is R — 386_GOTOFF
  • the linker 130 initiates the code folding process 240 ( 215 ).
  • a first scheme involves identifying a “black list” of functions that have operations on their respective addresses, which are deemed “unsafe” for code folding, and prevent any function in the black list from code folding even if it is identical to another function. As will be explained below, this scheme is relatively easy implement with an update to the linker programs.
  • a second scheme involves merging a source identical function (i.e., the function to be deleted from the executable program) with a target identical function (i.e., the function that remains in the executable program) by inserting a predefined instruction (e.g., a no-op instruction) before the target function and redirecting all the references to the source function or its address to the predefined instruction.
  • a predefined instruction e.g., a no-op instruction
  • the second scheme is further divided into two sub-schemes: (i) a first sub-scheme that involve inserting a predefined instruction regardless of whether the source identical function has any “unsafe” operation on the function's address; and (ii) a second sub-scheme that involves inserting a predefined instruction only if the source identical function is deemed to have an “unsafe” operation on the function's address.
  • both schemes above are illustrated by the flow chart shown in FIG. 2 with some of the steps (e.g., 250, 255) corresponding to one scheme (e.g., the “black list” scheme) and some of the steps (e.g., 230) corresponding to the other scheme (e.g., the “no-op” scheme).
  • the linker 130 determines whether or not it generates a black list of functions risky for code folding by, e.g., checking a function's associated relocation type ( 245 ).
  • the relocation type's value may indicate whether the function has any “unsafe” operation on its address (e.g., address comparison). If the linker 130 chooses to generate a black list of potentially risky functions ( 245 —yes), the linker 130 examines the relocation types associated with different functions in the object code ( 250 ).
  • the linker 130 Because the linker 130 knows in advance the architecture of the target processor for which the executable is generated and the type of machine instruction code of the executable, it can conduct a table lookup to determine which function's relocation types represent potentially “unsafe” operations on the function's address and which function's relocation types represent “safe” operations from the perspective of code folding. Based on the identified relocation types, the linker 130 identifies a black list of functions that should not be folded ( 255 ). If the linker 130 chooses to the no-op scheme ( 245 —no), which does not have a black list of functions, the steps 250 and 255 can be skipped.
  • the linker 130 identifies identical functions for code folding ( 260 ).
  • the linker 130 generates a checksum or the like for each function based on its content (e.g., the object code) and compares two functions' checksums to determine whether they are identical or not. For example, two functions that have the same checksum are deemed to be identical whereas two functions that do not have the same checksum are deemed to be different from each other.
  • the linker 130 performs the aforementioned checksum comparison to only those functions not identified in the black list such that all the identical functions are safe to be merged. If there is no black list, the linker 130 then applies the “no-op” approach to the identical functions identified at step 260 .
  • the linker 130 uses a data structure (e.g., a hash table) for sorting the functions found in the object code ( 265 ).
  • FIG. 3B depicts an exemplary hash table for this purpose in accordance with some embodiments. Note that each key ( 340 -A, 340 -B), which is a function's checksum, is mapped to a corresponding value ( 360 -A, 360 -B) by a hash function 350 .
  • the hash function 350 is configured to map different functions having different checksums (e.g., 340 -B and 340 -A) to different values (e.g., 360 -B and 360 -A) and map different functions having the checksums (e.g., 340 -A and 340 -A′) to the same value (e.g., 360 -A) such that the two functions' IDs are stored in the same bucket (e.g., 360 -A and 360 -A′).
  • checksums e.g., 340 -B and 340 -A
  • the checksums e.g., 340 -A and 340 -A′
  • the code folding operation is performed as part of the main linking process 200 after the generation of the hash table.
  • the linker 130 needs to determine whether it should use the “black list” approach or the “no-op” approach ( 225 ). If the “black list” approach is adopted ( 225 —no), the linker 130 then merges the identical functions in the hash table and automatically retains those identical functions in the black list ( 235 ) because the latter ones are either not present in the hash table or treated as unique ones.
  • the “black list” approach does not have to use the relocation type and it is possible for the linker 130 (or in some embodiments, the compiler 110 ) to analyze the object code to identify a black list of “unsafe” functions that may be more accurate than using the relocation type. If the compiler 110 is used for this purpose, it may store the black list of “unsafe” functions in a data structure shared with the linker 130 . If the “no-op” approach is chosen ( 225 —yes), the linker 130 will generate a no-op operation for each identical function found in the hash table as described above ( 230 ).
  • the linker 130 may use a hybrid scheme of the “no-op” approach and the “black list” approach such that the number of “no-op” instructions generated varies depending on whether those identical, but “unsafe,” functions have been distinguished from those identical, but “safe,” functions in the hash table.
  • the linker 130 checks whether the functions are in the black list or not. If they are in the black list, the linker 130 will delete the source function from the executable program, generate a “no-op” instruction before the target function, and direct any function address related operation to the address of the “no-op” instruction. Otherwise, if two identical functions do not have any “unsafe” operation, the linker 130 may delete the source function from the executable program and direct any function address related operation to the address of the target function.
  • FIG. 4A is a flow chart of a process for optimizing an executable program at a computer that has memory and one or more processors in accordance with some embodiments.
  • the computer receives one or more object code units from the memory ( 400 ).
  • the one or more object code units are one or more object code files and the computer receives them in connection with executing a linker application.
  • the computer identifies, among the one or more object code units, a first program entity and a first set of operations associated with the first program entity and a second program entity and a second set of operations associated with the second program entity ( 410 ), each program entity having an object code segment and an associated address.
  • a program entity may correspond to a function or a read-only data member.
  • the first and second program entities are identical if their object code segments are identical but have different addresses.
  • at least one operation from the first set operates on the address of the first program entity. This operation may be selected from the group consisting of an address comparison and an address modification that includes, e.g., increasing/decreasing the address or calculating another address using the address.
  • the computer updates the one or more object code units by causing the second set of operations to be associated with the first program entity if the first program entity's object code segment is identical to the second program entity's object code segment and no operation from the second set operates on the address of the second program entity ( 420 ) and combines the updated one or more object code units into an executable program ( 430 ).
  • the computer updates the one or more object code units by generating a first checksum using the first program entity's object code segment and a second checksum using the second program entity's object code segment; and comparing the first checksum with the second checksum to determine whether the first program entity's object code segment is identical to the second program entity's object code segment.
  • the computer compares the first checksum with the second checksum by generating a ⁇ key, value> pair in a hash table for the first program entity, wherein the key is the first program entity's checksum and the value is the first program entity's address; querying the hash table for a value using the second checksum as a key; and determines that the two program entities' object code segments are identical if the queried value is the first program entity's address or different if the queried value is the second program entity's address.
  • the computer updates the one or more object code units by, for a respective operation of the second set, identifying a property (e.g., a relocation type of the respective operation) associated with the respective operation; and comparing the identified property with a predefined value to determine whether the respective operation operates on the address of the second program entity.
  • the updating further includes deleting the second program entity's object code segment from the executable program.
  • FIG. 4B is a flow chart of a process for optimizing an executable program at a computer that has memory and one or more processors in accordance with some embodiments. This process is similar to the process described above in connection with FIG. 4A except that the computer updates the one or more object code units by inserting a predefined instruction (e.g., a no-op instruction that has a different address from the first program entity's address) before the first program entity's object code segment and causing the second set of operations to be associated with the predefined instruction if the first program entity's object code segment is identical to the second program entity's object code segment.
  • a predefined instruction e.g., a no-op instruction that has a different address from the first program entity's address
  • the second set includes at least one operation that operates on the address of the second program entity before the update of the one or more object code units and operates on the address of the predefined instruction after the update of the one or more object code units. In some other embodiments, the second set includes no operation that operates on the address of the second program entity.
  • the computer updates the one or more object code units by generating a first checksum using the first program entity's object code segment and a second checksum using the second program entity's object code segment; and comparing the first checksum with the second checksum to determine whether the first program entity's object code segment is identical to the second program entity's object code segment.
  • the computer compares the first checksum with the second checksum by generating a ⁇ key, value> pair in a hash table for the first program entity, wherein the key is the first program entity's checksum and the value is the first program entity's address; querying the hash table for a value using the second checksum as a key; and determines that the two program entities' object code segments are identical if the queried value is the first program entity's address or different if the queried value is the second program entity's address.
  • the computer updates the one or more object code units by, for a respective operation of the second set, identifying a property (e.g., a relocation type of the respective operation) associated with the respective operation; and comparing the identified property with a predefined value to determine whether the respective operation operates on the address of the second program entity.
  • the updating further includes deleting the second program entity's object code segment from the executable program.
  • an embodiment of a computer system 500 that implements the methods described above includes one or more processing units (CPU's) 502 , one or more network or other communications interfaces 510 , memory 512 , and one or more communication buses 514 for interconnecting these components. In some embodiments, fewer and/or additional components, modules or functions are included in the computer system 500 .
  • the communication buses 514 may include circuitry (sometimes called a chipset) that interconnects and controls communications between system components.
  • the computer system 500 may optionally include a user interface 504 .
  • the user interface 504 includes a display device 508 and/or a keyboard 506 , but other configurations of user interface devices may be used as well.
  • Memory 512 may include high speed random access memory and may also include non-volatile memory, such as one or more magnetic or optical storage disks, flash memory devices, or other non-volatile solid state storage devices.
  • the high speed random access memory may include memory devices such as DRAM, SRAM, DDR RAM or other random access solid state memory devices.
  • Memory 512 may optionally include mass storage that is remotely located from CPU's 502 .
  • Memory 512 or alternately the non-volatile memory device(s) within memory 512 , comprises a computer readable storage medium. Memory 512 stores the following elements, or a subset of these elements, and may also include additional elements:
  • stages which are not order dependent may be reordered and other stages may be combined or broken out. While some reordering or other groupings are specifically mentioned, others will be obvious to those of ordinary skill in the art and so do not present an exhaustive list of alternatives. Moreover, it should be recognized that the stages could be implemented in hardware, firmware, software or any combination thereof.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

A system and method for optimizing the object codes of a computer program is disclosed. The method includes receiving one or more object code units associated with an executable program; identifying, among the object code units, a first program entity and a first set of operations associated with the first program entity and a second program entity and a second set of operations associated with the second program entity, each program entity having an object code segment and an associated address; updating the object code units by inserting a predefined instruction before the first program entity's object code segment and causing the second set of operations to be associated with the predefined instruction if the first program entity's object code segment is identical to the second program entity's object code segment; and combining the updated object code units into the executable program.

Description

TECHNICAL FIELD
The disclosed embodiments relate generally to program compilation and linking, and in particular, to a system and method for optimizing an executable program by merging identical program entities such as functions or read-only data members in the executable program.
BACKGROUND
Large binary programs (e.g., applications or shared libraries written in C++) often have many functions or read-only data members that are identical. Although the size of a binary program may be reduced by merging these identical functions or read-only data members into a single copy, this optimization could be risky because it may cause the binary program to behave incorrectly if the merged functions or read-only data members are involved in certain address-related operations (e.g., address-based comparison) during the execution of the binary program.
SUMMARY
In accordance with some embodiments described below, a method for optimizing the object code of a program using a computer is disclosed. The computer-implemented method includes: receiving one or more object code units associated with an executable program; identifying, among the one or more object code units, a first program entity and a first set of operations associated with the first program entity and a second program entity and a second set of operations associated with the second program entity, wherein each program entity has an object code segment and an associated address; updating the one or more object code units by causing the second set of operations to be associated with the first program entity if the first program entity's object code segment is identical to the second program entity's object code segment and no operation from the second set operates on the address of the second program entity; and combining the updated one or more object code units into the executable program.
In accordance with some embodiments described below, a system for optimizing an executable program includes one or more central processing units for executing programs; and memory to store data and to store one or more programs to be executed by the one or more central processing units. The one or more programs include instructions for: receiving one or more object code units associated with an executable program; identifying, among the one or more object code units, a first program entity and a first set of operations associated with the first program entity and a second program entity and a second set of operations associated with the second program entity, wherein each program entity has an object code segment and an associated address; updating the one or more object code units by causing the second set of operations to be associated with the first program entity if the first program entity's object code segment is identical to the second program entity's object code segment and no operation from the second set operates on the address of the second program entity; and combining the updated one or more object code units into the executable program.
In accordance with some embodiments described below, a computer readable-storage medium stores one or more programs for execution by one or more processors of a computer system. The one or more programs include instructions for: receiving one or more object code units associated with an executable program; identifying, among the one or more object code units, a first program entity and a first set of operations associated with the first program entity and a second program entity and a second set of operations associated with the second program entity, wherein each program entity has an object code segment and an associated address; updating the one or more object code units by causing the second set of operations to be associated with the first program entity if the first program entity's object code segment is identical to the second program entity's object code segment and no operation from the second set operates on the address of the second program entity; and combining the updated one or more object code units into the executable program.
In accordance with some embodiments described below, a method for optimizing the object code of a program using a computer is disclosed. The computer-implemented method includes: receiving one or more object code units associated with an executable program; identifying, among the one or more object code units, a first program entity and a first set of operations associated with the first program entity and a second program entity and a second set of operations associated with the second program entity, wherein each program entity has an object code segment and an associated address; updating the one or more object code units by inserting a predefined instruction before the first program entity's object code segment and causing the second set of operations to be associated with the predefined instruction if the first program entity's object code segment is identical to the second program entity's object code segment; and combining the updated one or more object code units into the executable program.
In accordance with some embodiments described below, a system for optimizing an executable program includes one or more central processing units for executing programs; and memory to store data and to store one or more programs to be executed by the one or more central processing units. The one or more programs include instructions for: receiving one or more object code units associated with an executable program; identifying, among the one or more object code units, a first program entity and a first set of operations associated with the first program entity and a second program entity and a second set of operations associated with the second program entity, wherein each program entity has an object code segment and an associated address; updating the one or more object code units by inserting a predefined instruction before the first program entity's object code segment and causing the second set of operations to be associated with the predefined instruction if the first program entity's object code segment is identical to the second program entity's object code segment; and combining the updated one or more object code units into the executable program.
In accordance with some embodiments described below, a computer readable-storage medium stores one or more programs for execution by one or more processors of a computer system. The one or more programs include instructions for: receiving one or more object code units associated with an executable program; identifying, among the one or more object code units, a first program entity and a first set of operations associated with the first program entity and a second program entity and a second set of operations associated with the second program entity, wherein each program entity has an object code segment and an associated address; updating the one or more object code units by inserting a predefined instruction before the first program entity's object code segment and causing the second set of operations to be associated with the predefined instruction if the first program entity's object code segment is identical to the second program entity's object code segment; and combining the updated one or more object code units into the executable program.
BRIEF DESCRIPTION OF DRAWINGS
The aforementioned embodiment of the invention as well as additional embodiments will be more clearly understood as a result of the following detailed description of the various aspects of the invention when taken in conjunction with the drawings. Like reference numerals refer to corresponding parts throughout the several views of the drawings.
FIG. 1A is an overview block diagram of a process for transforming source codes of a program into an executable program in accordance with some embodiments.
FIGS. 1B and 1C illustrate an example of merging identical functions in an executable program in accordance with some embodiments.
FIG. 2 is a flow chart of a process for merging identical functions in connection with a linking progress in accordance with some embodiments.
FIG. 3A is a block diagram of a relocation data structure in accordance with some embodiments.
FIG. 3B is a block diagram of a hash data structure in accordance with some embodiments.
FIGS. 4A and 4B are flow charts of a process for optimizing an executable program in accordance with some embodiments.
FIG. 5 is a block diagram of a system for code optimization in accordance with some embodiments.
 DESCRIPTION OF EMBODIMENTS
Reference will now be made in detail to embodiments, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with the embodiments, it will be understood that the invention is not limited to these particular embodiments. On the contrary, the invention includes alternatives, modifications and equivalents that are within the spirit and scope of the appended claims. Numerous specific details are set forth in order to provide a thorough understanding of the subject matter presented herein. But it will be apparent to one of ordinary skill in the art that the subject matter may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.
FIG. 1A is an overview block diagram of a process for transforming the source code of a program into an executable program in accordance with some embodiments. In some embodiments, the program's source code is stored within one or more source code files 100-1 to 100-M. A compiler 110 transforms the source code files into one or more object code files 120-1 to 120-N. Depending on the size of the executable program, the number of object code files ranges from a few to hundreds or even thousands. In some embodiments, the compiler 110 may include other components such as an assembler. The process of compiling a program from a human-readable format such as source code into the binary format that a processor executes involves successively transforming the source code into simpler forms and discarding redundant information at each step until the result is a sequence of simple operations, register names, memory addresses, and binary values that the processor can understand. During this process, instructions within one source code file may be distributed over multiple object code files and instructions within multiple source code files may be merged into a single object code file. The linker 130 is a program that combines the one or more object files 120-1 to 120-N generated by the compiler 110 into a single binary executable program 140, which can be executed on a specific computer platform.
As noted above, an executable program may be generated by combining a large number of object code files. Many of these object code files may have identical code segments such as identical functions or read-only data members. Note that although identical source code segments may result in an identical object code segment, different source code segments may still be associated with an identical object code segment if the source code differences are “ignored” by the compiler 110.
FIG. 1B illustrates an exemplary program that has two source code files, “A.cc” 150 and “B.cc” 155. In particular, the source code file 150 includes a definition of a function Fn1( ) and the source code file 155 includes a definition of another function Fn2( ). Although the two functions are not identical at the source code level, their object code counterparts are identical. Besides the function Fn1( ) the source code file 150 includes a main( )function that has at least two function calls, one call of Fn1( ) 160 and another call of Fn2( ) 165.
As shown in FIG. 1B, each of the two source code files 150 and 155 is compiled into a separate object code file “A.o” 170 or “B.o” 175. In some embodiments, the compiler 110 assumes that every function in a source code file is different from another function in the same source code file or another source file and therefore assigns a unique address to each function in the object code. In this example, it is assumed that the address of the function Fn1( ) in the object code file 170 is 0xa123 and the address of the function Fn2( ) in the object code file 175 is 0xa134. The binary executable 180 generated by the linker 130 in accordance with the two object code files (along with other object code files if any) will have two copies of identical binary functions, one for the function Fn1( ) and the other one for the function Fn2( ).
FIG. 1C illustrates an example of merging identical functions in an executable program in accordance with some embodiments. In some embodiments, the process of merging identical functions into a single copy is referred to as “code folding.” As shown in FIG. 1C, the symbol table before the code folding has two entries associated with the two symbols Fn1 and Fn2. These two symbols represent two different functions in the source code and are associated with two different addresses 0xa123 and 0xa134, each address corresponding to a respective function in the source code. Because the two functions are identical at the object code level, it is possible to update the symbol table by merging the two functions into one copy. In this example, it is assumed that the object code corresponding to the function Fn1( ) is kept and the object code corresponding to the function Fn2( ) is eliminated such that the address associated with the symbol Fn2 in the symbol table changes from “0xa134” 185 to “0xa123” 190. Note that there are many well-known methods of determining whether two functions are identical to each other at the object code level. A more detailed description of such methods is provided below in connection with FIG. 3B.
One of the assumptions underlying the code folding examples illustrated above is that the program does not have an operation that manipulates the original address 0xa134 of the function Fn2. For example, if the program has the following operations (which are expressed in pseudo code):
    • if (Fn1==Fn2)
    • {
      • set flag 1;
    • }
    • else
    • {
      • set flag 2;
    • }
      the outcome based on the symbol table before code folding (i.e., Fn1≠Fn2) will be different from the outcome based on the symbol table after code folding (i.e., Fn1=Fn2). In other words, if the linker 130 has a code optimization option of merging identical code segments, it should exercise this option carefully to avoid causing incorrect behavior by the optimized program. It is worth noting that the process of merging identical read-only data members is similar to the process of merging identical functions. For illustration, the following description focuses on the process of merging identical functions.
FIG. 2 is a flow chart of a process for merging identical functions in connection with a linking progress in accordance with some embodiments. As will be explained below, this process sums up at least four different embodiments of performing code folding, each embodiment providing a unique aspects for merging identical functions. In some embodiments, the code folding process 240 is an auxiliary process associated with the main linking process 200. When the main linking process 200 chooses to optimize the object code by merging identical functions or read-only data members, the code folding process 240 is initiated, e.g., via a different thread. The main linking process 200 begins with reading (210) the symbols, relocations, and objects associated with an executable program. Note that a relocation data structure is a well-known entity used in the art of program compiling and linking. For each reference (or call) to a function or its corresponding address in the executable program, the compiler 110 generates a relocation entry at the compilation time and stores the relocation entry within a data structure as part of the object code. In some embodiments, a relocation entry has an attribute that can be used to determine whether a reference is associated with a function or its address.
FIG. 3A is a block diagram of a relocation data structure in accordance with some embodiments. The relocation data structure 300 includes multiple attributes for generating the executables by the linker 130 such as relocation type 310, relocation symbol name 320, and relocation symbol value 330. In some embodiments, the relocation type 310 is an attribute that depends on: (i) the architecture of the target processor for which the executable is generated, (ii) the type of machine instruction code constituting the executable, and (iii) whether the relocation is associated with a reference to a function or a reference to a function address. The relocation types 310 are commonly represented using standard names or designations, some examples of which are shown in the table below. This table shows the relocation type names associated with combinations of different executable object types (e.g., position-independent executable (PIE) objects and position-independent code (PIC) objects) and different relocation reference types, all for target processors that are compatible with an i386 instruction set architecture. Note that one skilled in the art would understand that the present invention is equally applicable to the relocation types of the other processor architectures that might have different naming standards.
For example, for target processors with an i386 instruction set architecture, there is a bifurcation between the relocation type 310 of a reference to a function and the relocation type of a reference to a function address for objects in the Executable and Linkable Format (ELF) as follows:
Executable/Shared Executable/Shared Executable/
libraries built with libraries built Shared
position- with position- libraries built
independent independent with non-PIC
executable (PIE) code (PIC) and non-PIE
objects objects objects
Function reference R_386_PC32 R_386_PLT32 R_386_PC32
relocation type
Function address R_386 _GOTOFF R_386_GOT32 R_386_32
reference relocation
type
In some embodiments, this property can be used to identify those operations on a function's address that may cause unsafe behavior if the function were merged with another identical function. Note that the use of relocation type as an indicator or proxy to determine whether two identical functions can be merged is merely one embodiment of the present application. One skilled in the art would understand that another property found in the object code may be used for similar purpose as long as the property demonstrates differences between a reference to a function and a reference to a function address. In some embodiments, such property may be derived from one or more attributes associated with the relocation or other information.
In some embodiments, the fact that a function is subject to an operation on its address (e.g., the function's relocation type is R—386_GOTOFF) only means that there is a potential risk of merging such function into another identical function but it does not necessarily guarantee that such merge would result in unsafe behavior. For example, if the operation does not compare the function's address with another function's address as illustrated above, it is still possible to merge the function with another identical one. In some embodiments, if only one of two identical functions has operations on its address while the other one does not, it is safe to merge the other one into the first one such that there is no operation on a substituting function address.
Returning to FIG. 2, in order to merge identical functions in the object code, the linker 130 initiates the code folding process 240 (215). In some embodiments, there are two code folding schemes for a linker to choose from. A first scheme involves identifying a “black list” of functions that have operations on their respective addresses, which are deemed “unsafe” for code folding, and prevent any function in the black list from code folding even if it is identical to another function. As will be explained below, this scheme is relatively easy implement with an update to the linker programs. A second scheme involves merging a source identical function (i.e., the function to be deleted from the executable program) with a target identical function (i.e., the function that remains in the executable program) by inserting a predefined instruction (e.g., a no-op instruction) before the target function and redirecting all the references to the source function or its address to the predefined instruction. Compared with the first scheme above, this second scheme can achieve a higher code reduction rate but requires more updates to existing linker programs. In some embodiments, the second scheme is further divided into two sub-schemes: (i) a first sub-scheme that involve inserting a predefined instruction regardless of whether the source identical function has any “unsafe” operation on the function's address; and (ii) a second sub-scheme that involves inserting a predefined instruction only if the source identical function is deemed to have an “unsafe” operation on the function's address. Note that both schemes above are illustrated by the flow chart shown in FIG. 2 with some of the steps (e.g., 250, 255) corresponding to one scheme (e.g., the “black list” scheme) and some of the steps (e.g., 230) corresponding to the other scheme (e.g., the “no-op” scheme).
At the beginning of the code folding process 240, the linker 130 determines whether or not it generates a black list of functions risky for code folding by, e.g., checking a function's associated relocation type (245). In some embodiments, as noted above, the relocation type's value may indicate whether the function has any “unsafe” operation on its address (e.g., address comparison). If the linker 130 chooses to generate a black list of potentially risky functions (245—yes), the linker 130 examines the relocation types associated with different functions in the object code (250). Because the linker 130 knows in advance the architecture of the target processor for which the executable is generated and the type of machine instruction code of the executable, it can conduct a table lookup to determine which function's relocation types represent potentially “unsafe” operations on the function's address and which function's relocation types represent “safe” operations from the perspective of code folding. Based on the identified relocation types, the linker 130 identifies a black list of functions that should not be folded (255). If the linker 130 chooses to the no-op scheme (245—no), which does not have a black list of functions, the steps 250 and 255 can be skipped.
In either case, the linker 130 identifies identical functions for code folding (260). In some embodiments, the linker 130 generates a checksum or the like for each function based on its content (e.g., the object code) and compares two functions' checksums to determine whether they are identical or not. For example, two functions that have the same checksum are deemed to be identical whereas two functions that do not have the same checksum are deemed to be different from each other. In some embodiments, the linker 130 performs the aforementioned checksum comparison to only those functions not identified in the black list such that all the identical functions are safe to be merged. If there is no black list, the linker 130 then applies the “no-op” approach to the identical functions identified at step 260.
In some embodiments, the linker 130 uses a data structure (e.g., a hash table) for sorting the functions found in the object code (265). FIG. 3B depicts an exemplary hash table for this purpose in accordance with some embodiments. Note that each key (340-A, 340-B), which is a function's checksum, is mapped to a corresponding value (360-A, 360-B) by a hash function 350. In some embodiments, the hash function 350 is configured to map different functions having different checksums (e.g., 340-B and 340-A) to different values (e.g., 360-B and 360-A) and map different functions having the checksums (e.g., 340-A and 340-A′) to the same value (e.g., 360-A) such that the two functions' IDs are stored in the same bucket (e.g., 360-A and 360-A′). By doing so, a unique function that does not have an identical counterpart always has a unique value in the hash table and identical functions automatically merge into one value in the hash table.
In some embodiments, the code folding operation is performed as part of the main linking process 200 after the generation of the hash table. To do so, the linker 130 needs to determine whether it should use the “black list” approach or the “no-op” approach (225). If the “black list” approach is adopted (225—no), the linker 130 then merges the identical functions in the hash table and automatically retains those identical functions in the black list (235) because the latter ones are either not present in the hash table or treated as unique ones. Note that the “black list” approach does not have to use the relocation type and it is possible for the linker 130 (or in some embodiments, the compiler 110) to analyze the object code to identify a black list of “unsafe” functions that may be more accurate than using the relocation type. If the compiler 110 is used for this purpose, it may store the black list of “unsafe” functions in a data structure shared with the linker 130. If the “no-op” approach is chosen (225—yes), the linker 130 will generate a no-op operation for each identical function found in the hash table as described above (230).
In some embodiments, the linker 130 may use a hybrid scheme of the “no-op” approach and the “black list” approach such that the number of “no-op” instructions generated varies depending on whether those identical, but “unsafe,” functions have been distinguished from those identical, but “safe,” functions in the hash table. In this hybrid approach, before merging identical functions, the linker 130 checks whether the functions are in the black list or not. If they are in the black list, the linker 130 will delete the source function from the executable program, generate a “no-op” instruction before the target function, and direct any function address related operation to the address of the “no-op” instruction. Otherwise, if two identical functions do not have any “unsafe” operation, the linker 130 may delete the source function from the executable program and direct any function address related operation to the address of the target function.
FIG. 4A is a flow chart of a process for optimizing an executable program at a computer that has memory and one or more processors in accordance with some embodiments. The computer receives one or more object code units from the memory (400). In some embodiments, the one or more object code units are one or more object code files and the computer receives them in connection with executing a linker application.
The computer then identifies, among the one or more object code units, a first program entity and a first set of operations associated with the first program entity and a second program entity and a second set of operations associated with the second program entity (410), each program entity having an object code segment and an associated address. For example, a program entity may correspond to a function or a read-only data member. In some embodiments, the first and second program entities are identical if their object code segments are identical but have different addresses. In some embodiments, at least one operation from the first set operates on the address of the first program entity. This operation may be selected from the group consisting of an address comparison and an address modification that includes, e.g., increasing/decreasing the address or calculating another address using the address.
The computer updates the one or more object code units by causing the second set of operations to be associated with the first program entity if the first program entity's object code segment is identical to the second program entity's object code segment and no operation from the second set operates on the address of the second program entity (420) and combines the updated one or more object code units into an executable program (430).
In some embodiments, the computer updates the one or more object code units by generating a first checksum using the first program entity's object code segment and a second checksum using the second program entity's object code segment; and comparing the first checksum with the second checksum to determine whether the first program entity's object code segment is identical to the second program entity's object code segment. In some embodiments, the computer compares the first checksum with the second checksum by generating a <key, value> pair in a hash table for the first program entity, wherein the key is the first program entity's checksum and the value is the first program entity's address; querying the hash table for a value using the second checksum as a key; and determines that the two program entities' object code segments are identical if the queried value is the first program entity's address or different if the queried value is the second program entity's address.
In some embodiments, the computer updates the one or more object code units by, for a respective operation of the second set, identifying a property (e.g., a relocation type of the respective operation) associated with the respective operation; and comparing the identified property with a predefined value to determine whether the respective operation operates on the address of the second program entity. In some embodiments, the updating further includes deleting the second program entity's object code segment from the executable program.
FIG. 4B is a flow chart of a process for optimizing an executable program at a computer that has memory and one or more processors in accordance with some embodiments. This process is similar to the process described above in connection with FIG. 4A except that the computer updates the one or more object code units by inserting a predefined instruction (e.g., a no-op instruction that has a different address from the first program entity's address) before the first program entity's object code segment and causing the second set of operations to be associated with the predefined instruction if the first program entity's object code segment is identical to the second program entity's object code segment.
In some embodiments, the second set includes at least one operation that operates on the address of the second program entity before the update of the one or more object code units and operates on the address of the predefined instruction after the update of the one or more object code units. In some other embodiments, the second set includes no operation that operates on the address of the second program entity.
In some embodiments, the computer updates the one or more object code units by generating a first checksum using the first program entity's object code segment and a second checksum using the second program entity's object code segment; and comparing the first checksum with the second checksum to determine whether the first program entity's object code segment is identical to the second program entity's object code segment. In some embodiments, the computer compares the first checksum with the second checksum by generating a <key, value> pair in a hash table for the first program entity, wherein the key is the first program entity's checksum and the value is the first program entity's address; querying the hash table for a value using the second checksum as a key; and determines that the two program entities' object code segments are identical if the queried value is the first program entity's address or different if the queried value is the second program entity's address.
In some embodiments, the computer updates the one or more object code units by, for a respective operation of the second set, identifying a property (e.g., a relocation type of the respective operation) associated with the respective operation; and comparing the identified property with a predefined value to determine whether the respective operation operates on the address of the second program entity. In some embodiments, the updating further includes deleting the second program entity's object code segment from the executable program.
Referring to FIG. 5, an embodiment of a computer system 500 that implements the methods described above includes one or more processing units (CPU's) 502, one or more network or other communications interfaces 510, memory 512, and one or more communication buses 514 for interconnecting these components. In some embodiments, fewer and/or additional components, modules or functions are included in the computer system 500. The communication buses 514 may include circuitry (sometimes called a chipset) that interconnects and controls communications between system components. The computer system 500 may optionally include a user interface 504. In some embodiments, the user interface 504 includes a display device 508 and/or a keyboard 506, but other configurations of user interface devices may be used as well. Memory 512 may include high speed random access memory and may also include non-volatile memory, such as one or more magnetic or optical storage disks, flash memory devices, or other non-volatile solid state storage devices. The high speed random access memory may include memory devices such as DRAM, SRAM, DDR RAM or other random access solid state memory devices. Memory 512 may optionally include mass storage that is remotely located from CPU's 502. Memory 512, or alternately the non-volatile memory device(s) within memory 512, comprises a computer readable storage medium. Memory 512 stores the following elements, or a subset of these elements, and may also include additional elements:
    • an operating system 516 that includes procedures for handling various system services and for performing hardware dependent tasks;
    • a network communication module (or instructions) 518 that is used for connecting the computer system 500 to other computers via the one or more communications network interfaces 510 and one or more communications networks, such as the Internet, other wide area networks, local area networks, metropolitan area networks, and so on;
    • a compiler and linker application 520 for processing the source code of a program written in a particular language such as C, C++, Java, etc. and generating the binary executable;
    • an object code folding module 522 for identifying identical program entities including functions and read-only data members in the object code and applying a code folding scheme to the identical program entities;
    • a hash table data structure 524 for storing information identifying program entities subject to code folding; and
    • one or more programs 526, each program further including source code 528, object code 530, and executables 532.
Although some of the various drawings illustrate a number of logical stages in a particular order, stages which are not order dependent may be reordered and other stages may be combined or broken out. While some reordering or other groupings are specifically mentioned, others will be obvious to those of ordinary skill in the art and so do not present an exhaustive list of alternatives. Moreover, it should be recognized that the stages could be implemented in hardware, firmware, software or any combination thereof.
The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated.

Claims (18)

What is claimed is:
1. A computer-implemented method, comprising:
at a computer having memory and one or more processors:
receiving one or more object code units associated with an executable program;
identifying, among the one or more object code units, a first program entity and a first set of operations associated with the first program entity and a second program entity and a second set of operations associated with the second program entity, wherein each program entity has an object code segment and an address of the object code segment and the first set of operations includes at least one reference to the address of the first program entity's object code segment and the second set of operations includes at least one reference to the address of the second program entity's object code segment;
when the first program entity's object code segment is identical to the second program entity's object code segment, updating the one or more object code units by generating and inserting a no-operation instruction in an address before the address of the first program entity's object code segment and causing the second set of operations to be associated with the no-operation instruction such that the at least one reference to the address of the second program entity's object code segment in the second set of operations is replaced with the address of the no-operation operation, wherein the no-operation instruction has an address different from the first program entity's address; and
combining the updated one or more object code units into the executable program.
2. The computer-implemented method of claim 1, wherein the second set includes at least one operation that operates on the address of the second program entity before the update of the one or more object code units and operates on the address of the no-operation instruction after the update of the one or more object code units.
3. The computer-implemented method of claim 2, wherein the at least one operation from the second set is one selected from the group consisting of an address comparison and an address modification.
4. The computer-implemented method of claim 1, wherein the second set includes no operation that operates on the address of the second program entity.
5. The computer-implemented method of claim 1, wherein updating the one or more object code units further includes:
generating a first checksum using the first program entity's object code segment and a second checksum using the second program entity's object code segment; and
comparing the first checksum with the second checksum to determine whether the first program entity's object code segment is identical to the second program entity's object code segment.
6. The computer-implemented method of claim 5, wherein comparing the first checksum with the second checksum further includes:
generating a <key, value> pair in a hash table for the first program entity, wherein the key is the first program entity's checksum and the value is the first program entity's address;
querying the hash table for a value using the second checksum as a key; and
determining that:
the two program entities' object code segments are identical if the queried value is the first program entity's address; and
the two program entities' object code segments are different if the queried value is the second program entity's address.
7. The computer-implemented method of claim 1, wherein updating the one or more object code units further includes:
deleting the second program entity's object code segment from the executable program.
8. The computer-implemented method of claim 1, wherein each of the first and second program entities corresponds to one selected from the group consisting of a function and a read-only data member.
9. A system for optimizing an executable program, comprising:
one or more central processing units for executing programs; and
memory to store data and to store one or more programs to be executed by the one or more central processing units, the one or more programs including instructions for:
receiving one or more object code units associated with an executable program;
identifying, among the one or more object code units, a first program entity and a first set of operations associated with the first program entity and a second program entity and a second set of operations associated with the second program entity, wherein each program entity has an object code segment and an address of the object code segment and the first set of operations includes at least one reference to the address of the first program entity's object code segment and the second set of operations includes at least one reference to the address of the second program entity's object code segment;
when the first program entity's object code segment is identical to the second program entity's object code segment, updating the one or more object code units by generating and inserting a no-operation instruction in an address before the address of the first program entity's object code segment and causing the second set of operations to be associated with the no-operation instruction such that the at least one reference to the address of the second program entity's object code segment in the second set of operations is replaced with the address of the predefined operation, wherein the no-operation instruction has an address different from the first program entity's address; and
combining the updated one or more object code units into the executable program.
10. The system of claim 9, wherein the second set includes no operation that operates on the address of the second program entity.
11. The system of claim 9, wherein the instructions for updating the one or more object code units further include:
instructions for generating a first checksum using the first program entity's object code segment and a second checksum using the second program entity's object code segment; and
instructions for comparing the first checksum with the second checksum to determine whether the first program entity's object code segment is identical to the second program entity's object code segment.
12. The system of claim 9, wherein the instructions for updating the one or more object code units further include:
instructions for deleting the second program entity's object code segment from the executable program.
13. The system of claim 9, wherein each of the first and second program entities corresponds to one selected from the group consisting of a function and a read-only data member.
14. A non-transitory computer readable-storage medium storing one or more programs for execution by one or more processors of a respective server system, the one or more programs comprising instructions for:
receiving one or more object code units associated with an executable program;
identifying, among the one or more object code units, a first program entity and a first set of operations associated with the first program entity and a second program entity and a second set of operations associated with the second program entity, wherein each program entity has an object code segment and an address of the object code segment and the first set of operations includes at least one reference to the address of the first program entity's object code segment and the second set of operations includes at least one reference to the address of the second program entity's object code segment;
when the first program entity's object code segment is identical to the second program entity's object code segment, updating the one or more object code units by generating and inserting a no-operation instruction in an address before the address of the first program entity's object code segment and causing the second set of operations to be associated with the no-operation instruction such that the at least one reference to the address of the second program entity's object code segment in the second set of operations is replaced with the address of the predefined operation, wherein the no-operation instruction has an address different from the first program entity's address; and
combining the updated one or more object code units into the executable program.
15. The non-transitory computer readable-storage medium of claim 14, wherein the second set includes no operation that operates on the address of the second program entity.
16. The non-transitory computer readable-storage medium of claim 14, wherein the instructions for updating the one or more object code units further include:
instructions for generating a first checksum using the first program entity's object code segment and a second checksum using the second program entity's object code segment; and
instructions for comparing the first checksum with the second checksum to determine whether the first program entity's object code segment is identical to the second program entity's object code segment.
17. The non-transitory computer readable-storage medium of claim 14, wherein the instructions for updating the one or more object code units further include:
instructions for deleting the second program entity's object code segment from the executable program.
18. The non-transitory computer readable-storage medium of claim 14, wherein each of the first and second program entities corresponds to one selected from the group consisting of a function and a read-only data member.
US13/005,394 2011-01-12 2011-01-12 Method and system for optimizing an executable program by generating special operations for identical program entities Expired - Fee Related US8689200B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/005,394 US8689200B1 (en) 2011-01-12 2011-01-12 Method and system for optimizing an executable program by generating special operations for identical program entities

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US13/005,394 US8689200B1 (en) 2011-01-12 2011-01-12 Method and system for optimizing an executable program by generating special operations for identical program entities

Publications (1)

Publication Number Publication Date
US8689200B1 true US8689200B1 (en) 2014-04-01

Family

ID=50349036

Family Applications (1)

Application Number Title Priority Date Filing Date
US13/005,394 Expired - Fee Related US8689200B1 (en) 2011-01-12 2011-01-12 Method and system for optimizing an executable program by generating special operations for identical program entities

Country Status (1)

Country Link
US (1) US8689200B1 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150089480A1 (en) * 2013-09-26 2015-03-26 Fujitsu Limited Device, method of generating performance evaluation program, and recording medium
US9535688B2 (en) * 2014-07-23 2017-01-03 Verizon Patent And Licensing Inc. Efficient deployment of application revisions and implementation of application rollbacks across multiple application servers
US9792098B2 (en) 2015-03-25 2017-10-17 International Business Machines Corporation Unaligned instruction relocation
US9841959B2 (en) 2015-02-02 2017-12-12 Google Llc Fine-grained demand driven IPO infrastructure
US20230359712A1 (en) * 2021-12-02 2023-11-09 Research & Business Foundation Sungkyunkwan University Method and device of embedding watermark in software

Citations (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4755966A (en) * 1985-06-28 1988-07-05 Hewlett-Packard Company Bidirectional branch prediction and optimization
US5327562A (en) 1992-05-06 1994-07-05 Microsoft Corporation Method for implementing virtual function tables in a compiler for an object-oriented programming language
US5524244A (en) * 1988-07-11 1996-06-04 Logic Devices, Inc. System for dividing processing tasks into signal processor and decision-making microprocessor interfacing therewith
US5535391A (en) * 1992-06-05 1996-07-09 Borland International, Inc. System and methods for optimizing object-oriented compilations
US5548761A (en) * 1993-03-09 1996-08-20 International Business Machines Corporation Compiler for target machine independent optimization of data movement, ownership transfer and device control
US5632034A (en) * 1993-06-01 1997-05-20 International Business Machines Corporation Controlling method invocation sequence through virtual functions in an object-oriented class library
US5713010A (en) 1995-02-10 1998-01-27 Hewlett-Packard Company Source line tracking in optimized code
US5799302A (en) 1995-03-30 1998-08-25 Pitney Bowes Inc. Method and system for minimizing attribute naming errors in set oriented duplicate detection
US5819074A (en) * 1996-12-05 1998-10-06 Hewlett-Packard Co. Method of eliminating unnecessary code generation in a circuit compiler
US5828886A (en) * 1994-02-23 1998-10-27 Fujitsu Limited Compiling apparatus and method for promoting an optimization effect of a program
US5854935A (en) * 1995-10-18 1998-12-29 Nec Corporation Program transformation system for microcomputer and microcomputer employing transformed program
US5892940A (en) * 1996-12-05 1999-04-06 Hewlett-Packard, Co. Aliasing nodes to improve the code generated by a circuit compiler
US5896521A (en) * 1996-03-15 1999-04-20 Mitsubishi Denki Kabushiki Kaisha Processor synthesis system and processor synthesis method
US5905893A (en) * 1996-06-10 1999-05-18 Lsi Logic Corporation Microprocessor adapted for executing both a non-compressed fixed length instruction set and a compressed variable length instruction set
US5920721A (en) * 1997-06-11 1999-07-06 Digital Equipment Corporation Compiler generating functionally-alike code sequences in an executable program intended for execution in different run-time environments
US6041180A (en) * 1997-04-28 2000-03-21 International Business Machines Corporation System and method for optimizing template object files
US6128627A (en) * 1998-04-15 2000-10-03 Inktomi Corporation Consistent data storage in an object cache
US20020013938A1 (en) * 2000-02-09 2002-01-31 Evelyn Duesterwald Fast runtime scheme for removing dead code across linked fragments
US6374235B1 (en) 1999-06-25 2002-04-16 International Business Machines Corporation Method, system, and program for a join operation on a multi-column table and satellite tables including duplicate values
US20030101431A1 (en) * 2001-11-29 2003-05-29 Evelyn Duesterwald System and method for dynamically replacing code
US6718546B1 (en) * 1999-04-23 2004-04-06 International Business Machines Corporation Application management
US20040221282A1 (en) * 2001-07-26 2004-11-04 Daniel Le Metayer Method for the compression of an interpreted code semantic analysis
US20050210208A1 (en) * 2004-03-19 2005-09-22 Li Long Methods and apparatus for merging critical sections
US20060064676A1 (en) 2004-09-21 2006-03-23 Hewlett-Packard Development Company, L.P. Systems and methods for validating debug information for optimized code
US7069555B1 (en) * 2000-09-29 2006-06-27 Microsoft Corporation Super-region instruction scheduling and code generation for merging identical instruction into the ready-to-schedule instruction
US20070006185A1 (en) * 2005-05-19 2007-01-04 Samsung Electronics Co., Ltd. System and method for reducing execution time of bytecode in java virtual machine
US7207038B2 (en) * 2003-08-29 2007-04-17 Nokia Corporation Constructing control flows graphs of binary executable programs at post-link time
US20080320246A1 (en) * 2001-12-26 2008-12-25 Fuhler Richard A Methods and apparatus for compiling instructions for a data processor
US20090138847A1 (en) * 2007-03-09 2009-05-28 Objective Interface Systems Optimized code generation by eliminating unused virtual function
US20090164757A1 (en) * 2007-12-20 2009-06-25 International Business Machines Corporation Method and Apparatus for Performing Out of Order Instruction Folding and Retirement
US20090172638A1 (en) * 2001-02-28 2009-07-02 Computer Associates Think, Inc. Adding Functionality To Existing Code At Exits
US20090241098A1 (en) 2008-03-18 2009-09-24 Sun Microsystems, Inc. Link-time redundant code elimination using functional equivalence
US20100017436A1 (en) * 2008-07-18 2010-01-21 Qliktech International Ab Method and Apparatus for Extracting Information From a Database
US7694300B2 (en) * 2004-12-06 2010-04-06 Microsoft Corporation Inter-process interference elimination
US20100162220A1 (en) * 2008-12-23 2010-06-24 International Business Machines Corporation Code Motion Based on Live Ranges in an Optimizing Compiler
US7840776B1 (en) * 1996-08-22 2010-11-23 Kelly Edmund J Translated memory protection apparatus for an advanced microprocessor
US20110107068A1 (en) * 2009-10-30 2011-05-05 International Business Machines Corporation Eliminating redundant operations for common properties using shared real registers
US20120030652A1 (en) 2010-07-30 2012-02-02 Jakub Jelinek Mechanism for Describing Values of Optimized Away Parameters in a Compiler-Generated Debug Output
US8321834B2 (en) 2008-09-25 2012-11-27 International Business Machines Corporation Framework for automatically merging customizations to structured code that has been refactored

Patent Citations (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4755966A (en) * 1985-06-28 1988-07-05 Hewlett-Packard Company Bidirectional branch prediction and optimization
US5524244A (en) * 1988-07-11 1996-06-04 Logic Devices, Inc. System for dividing processing tasks into signal processor and decision-making microprocessor interfacing therewith
US5327562A (en) 1992-05-06 1994-07-05 Microsoft Corporation Method for implementing virtual function tables in a compiler for an object-oriented programming language
US5535391A (en) * 1992-06-05 1996-07-09 Borland International, Inc. System and methods for optimizing object-oriented compilations
US5548761A (en) * 1993-03-09 1996-08-20 International Business Machines Corporation Compiler for target machine independent optimization of data movement, ownership transfer and device control
US5632034A (en) * 1993-06-01 1997-05-20 International Business Machines Corporation Controlling method invocation sequence through virtual functions in an object-oriented class library
US5828886A (en) * 1994-02-23 1998-10-27 Fujitsu Limited Compiling apparatus and method for promoting an optimization effect of a program
US5713010A (en) 1995-02-10 1998-01-27 Hewlett-Packard Company Source line tracking in optimized code
US5799302A (en) 1995-03-30 1998-08-25 Pitney Bowes Inc. Method and system for minimizing attribute naming errors in set oriented duplicate detection
US5854935A (en) * 1995-10-18 1998-12-29 Nec Corporation Program transformation system for microcomputer and microcomputer employing transformed program
US5896521A (en) * 1996-03-15 1999-04-20 Mitsubishi Denki Kabushiki Kaisha Processor synthesis system and processor synthesis method
US5905893A (en) * 1996-06-10 1999-05-18 Lsi Logic Corporation Microprocessor adapted for executing both a non-compressed fixed length instruction set and a compressed variable length instruction set
US7840776B1 (en) * 1996-08-22 2010-11-23 Kelly Edmund J Translated memory protection apparatus for an advanced microprocessor
US5892940A (en) * 1996-12-05 1999-04-06 Hewlett-Packard, Co. Aliasing nodes to improve the code generated by a circuit compiler
US5819074A (en) * 1996-12-05 1998-10-06 Hewlett-Packard Co. Method of eliminating unnecessary code generation in a circuit compiler
US6041180A (en) * 1997-04-28 2000-03-21 International Business Machines Corporation System and method for optimizing template object files
US5920721A (en) * 1997-06-11 1999-07-06 Digital Equipment Corporation Compiler generating functionally-alike code sequences in an executable program intended for execution in different run-time environments
US6128627A (en) * 1998-04-15 2000-10-03 Inktomi Corporation Consistent data storage in an object cache
US6718546B1 (en) * 1999-04-23 2004-04-06 International Business Machines Corporation Application management
US6374235B1 (en) 1999-06-25 2002-04-16 International Business Machines Corporation Method, system, and program for a join operation on a multi-column table and satellite tables including duplicate values
US20020013938A1 (en) * 2000-02-09 2002-01-31 Evelyn Duesterwald Fast runtime scheme for removing dead code across linked fragments
US7069555B1 (en) * 2000-09-29 2006-06-27 Microsoft Corporation Super-region instruction scheduling and code generation for merging identical instruction into the ready-to-schedule instruction
US20090172638A1 (en) * 2001-02-28 2009-07-02 Computer Associates Think, Inc. Adding Functionality To Existing Code At Exits
US7467376B2 (en) * 2001-07-26 2008-12-16 Trusted Logic Semantic analysis based compression of interpreted code by replacing object instruction groups with special instruction specifying a register representing the object
US20040221282A1 (en) * 2001-07-26 2004-11-04 Daniel Le Metayer Method for the compression of an interpreted code semantic analysis
US20030101431A1 (en) * 2001-11-29 2003-05-29 Evelyn Duesterwald System and method for dynamically replacing code
US20080320246A1 (en) * 2001-12-26 2008-12-25 Fuhler Richard A Methods and apparatus for compiling instructions for a data processor
US7207038B2 (en) * 2003-08-29 2007-04-17 Nokia Corporation Constructing control flows graphs of binary executable programs at post-link time
US7392513B2 (en) * 2004-03-19 2008-06-24 Intel Corporation Methods and apparatus for merging critical sections
US20050210208A1 (en) * 2004-03-19 2005-09-22 Li Long Methods and apparatus for merging critical sections
US20060064676A1 (en) 2004-09-21 2006-03-23 Hewlett-Packard Development Company, L.P. Systems and methods for validating debug information for optimized code
US7607123B2 (en) 2004-09-21 2009-10-20 Hewlett-Packard Development Company, L.P. Systems and methods for validating debug information for optimized code
US7694300B2 (en) * 2004-12-06 2010-04-06 Microsoft Corporation Inter-process interference elimination
US20070006185A1 (en) * 2005-05-19 2007-01-04 Samsung Electronics Co., Ltd. System and method for reducing execution time of bytecode in java virtual machine
US20090138847A1 (en) * 2007-03-09 2009-05-28 Objective Interface Systems Optimized code generation by eliminating unused virtual function
US20090164757A1 (en) * 2007-12-20 2009-06-25 International Business Machines Corporation Method and Apparatus for Performing Out of Order Instruction Folding and Retirement
US7836282B2 (en) * 2007-12-20 2010-11-16 International Business Machines Corporation Method and apparatus for performing out of order instruction folding and retirement
US20090241098A1 (en) 2008-03-18 2009-09-24 Sun Microsystems, Inc. Link-time redundant code elimination using functional equivalence
US20100017436A1 (en) * 2008-07-18 2010-01-21 Qliktech International Ab Method and Apparatus for Extracting Information From a Database
US8321834B2 (en) 2008-09-25 2012-11-27 International Business Machines Corporation Framework for automatically merging customizations to structured code that has been refactored
US20100162220A1 (en) * 2008-12-23 2010-06-24 International Business Machines Corporation Code Motion Based on Live Ranges in an Optimizing Compiler
US20110107068A1 (en) * 2009-10-30 2011-05-05 International Business Machines Corporation Eliminating redundant operations for common properties using shared real registers
US20120030652A1 (en) 2010-07-30 2012-02-02 Jakub Jelinek Mechanism for Describing Values of Optimized Away Parameters in a Compiler-Generated Debug Output

Non-Patent Citations (10)

* Cited by examiner, † Cited by third party
Title
Diwan, Using Types to Analyze and Optimize Object-Oriented Programs, UMass, 2001, 42 pgs.
DWARF Debugging information format version 3, Dec. 20, 2005, 267 pgs.
Ilfak Guilfanov , "IDA and obfuscated code", Hex-Rays , 1998 , , pp. 1-44. *
Ilfak Guilfanov , "IDA and obfuscated code", Hex-Rays , 1998 , <www.hex-rays.com/products/ida/support/ppt/caro—obfuscation.ppt> , pp. 1-44. *
Tallam, Notice of Allowance, U.S. Appl. No. 13/005,375, Jan. 25, 2013, 9 pgs.
Toshio Suganuma et al. , "Design and Evaluation of Dynamic Optimizations for a Java Just-In-Time Compiler", ACM , 2005 , , pp. 1-54. *
Toshio Suganuma et al. , "Design and Evaluation of Dynamic Optimizations for a Java Just-In-Time Compiler", ACM , 2005 , <http://delivery.acm.org/10.1145/1080000/1075386/p732-suganuma.pdf> , pp. 1-54. *
Tuvi Etzion , "Folding, Tiling, and Multidimensional Coding", IEEE, 2009, , pp. 1-5. *
Tuvi Etzion , "Folding, Tiling, and Multidimensional Coding", IEEE, 2009, <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5351265> , pp. 1-5. *
Zellweger, An interactive high-level debugger for control-flow optimized programs, Jan. 1983, 30 pgs.

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150089480A1 (en) * 2013-09-26 2015-03-26 Fujitsu Limited Device, method of generating performance evaluation program, and recording medium
US9519567B2 (en) * 2013-09-26 2016-12-13 Fujitsu Limited Device, method of generating performance evaluation program, and recording medium
US9535688B2 (en) * 2014-07-23 2017-01-03 Verizon Patent And Licensing Inc. Efficient deployment of application revisions and implementation of application rollbacks across multiple application servers
US9841959B2 (en) 2015-02-02 2017-12-12 Google Llc Fine-grained demand driven IPO infrastructure
US9792098B2 (en) 2015-03-25 2017-10-17 International Business Machines Corporation Unaligned instruction relocation
US20230359712A1 (en) * 2021-12-02 2023-11-09 Research & Business Foundation Sungkyunkwan University Method and device of embedding watermark in software
US12517988B2 (en) * 2021-12-02 2026-01-06 Research & Business Foundation Sungkyunkwan University Method and device of embedding watermark in software

Similar Documents

Publication Publication Date Title
US9218169B2 (en) Callpath finder
US20230117105A1 (en) On-demand loading of dynamic scripting language code for reduced memory usage
US20180189371A1 (en) Updating sqlite database
CN107392619A (en) Intelligent contract processing method and processing device
JP2016519385A (en) Method for loading driver and embedded device
US9384364B1 (en) System and method of controlling access of a native image of a machine code to operating system resources
US10904316B2 (en) Data processing method and apparatus in service-oriented architecture system, and the service-oriented architecture system
CN111538651A (en) Interface testing method, device, server and storage medium
US8418161B2 (en) System and method for loading a called class file table with data indicating a highest version of a class file
CN106528071A (en) Selection method and device for target code
CN113515303A (en) Project transformation method, device and equipment
JP2013534347A (en) System and method for execution of high performance computing applications
EP3121750B1 (en) System and method for antivirus checking of native images of software assemblies
CN111930363B (en) Block interface code generation method and device
US10747514B2 (en) Reduced save and restore instructions for call-clobbered registers
US8683455B1 (en) Method and system for optimizing an executable program by selectively merging identical program entities
US8762976B2 (en) Static extensibility models with dynamic languages and scripts
US10310871B2 (en) Non-transitory computer-readable recording medium storing control program, control device and control method
CN108197020A (en) Plug-in unit method of calibration, electronic equipment and computer storage media
CN112486465B (en) Code updating method and device
US10671397B2 (en) Reduced save and restore instructions for call-clobbered registers
WO2023169164A1 (en) Method and apparatus for restoring application program, and computer device and storage medium
US9098317B2 (en) Optional retargeting of library references
US8984475B2 (en) Apparatus and method for generating code overlay
CN106502707B (en) Code generation method and device

Legal Events

Date Code Title Description
AS Assignment

Owner name: GOOGLE INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:TALLAM, SRIRAMAN;TAYLOR, IAN LANCE;COUTANT, CARY;AND OTHERS;REEL/FRAME:025627/0737

Effective date: 20110111

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: GOOGLE LLC, CALIFORNIA

Free format text: CHANGE OF NAME;ASSIGNOR:GOOGLE INC.;REEL/FRAME:044101/0299

Effective date: 20170929

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551)

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8

FEPP Fee payment procedure

Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

LAPS Lapse for failure to pay maintenance fees

Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362