Abstract: Under the present invention, program code is examined (statically or dynamically) for characteristics indicative of a potential to generate multiple threads. If none are found, single threaded optimization(s) such as desynchronization, optimization of globals, etc., can be implemented. In addition, if the program code is later revealed to have the potential to generate multiple threads, the single threaded optimization(s) can be corrected to avoid incorrect execution.

Abstract: Optimizations are programmatically applied by a compiler (preferably, a just-in-time or “JIT” compiler), and enable achieving improved performance while a variable acts as a global constant, yet also allow code to execute correctly if the global constant's run-time value changes from the value on which the optimization was originally based. Code snippets that dynamically patch executable code are described, where these code snippets take corrective actions to enable correct program execution following a run-time change to the value of a glacial constant. A backup recovery path may also be maintained, where this path provides code that is executed in the event of a change to a glacial constant and that treats the glacial constant as a variable. Recompilation may also be used after a change to a glacial constant, where the originally-compiled code has made an assumption about the glacial constant's value that is no longer accurate. Combinations of these approaches may be used.

Abstract: Synchronizing clones of a software method to be executed by at least one thread while the software method is compiled. The software method is cloned to generate a software method clone. At least one transition is created between equivalent program points in the software method and the software method clone. A lock object is inserted into one of the software method and the software method clone. Then, code that controls the at least one transition between a profiling clone and a non-profiling clone is changed to access thread-local storage. The non-profiling clone is the one of the software method and the software method clone into which the lock object was inserted. A first synchronization operation is performed at or after an entry point of the non-profiling clone. Then, the profiling clone is executed using thread-local storage.

Abstract: A computer-implemented method, computer program product and data processing system to improve runtime performance of executable program code when executed on the data-processing system. During execution, data is collected and analyzed to identify runtime behavior of the program code. Heuristic models are applied to select region(s) of the program code where application of a performance improvement algorithm is expected to improve runtime performance. Each selected region is recompiled using selected performance improvement algorithm(s) for that region to generate corresponding recompiled region(s), and the program code is modified to replace invocations of each selected region with invocations of the corresponding recompiled region. Alternatively or additionally, the program code may be recompiled to be adapted to characteristics of the execution environment of the data processing system.

Abstract: Under the present invention, a branch target address corresponding to a target instruction to be pre-fetched is predicted based on two values. The first value is a “predictor value” that is known for the branch target address. The second value is the address of the branch instruction from which the target instruction is branched to within the program code. Once these two values are provided, they can be processed (e.g., hashed) to yield an index value, which is used to obtain a predicted branch target address from a cache. This technique is generally implemented for branch instructions such as switch statements or polymorphic calls. In the case of the former, the predictor value is a selector operand, while in the case of the latter the predictor value is a class object address (in JAVA) or a virtual function table address (in C++).

Abstract: A locking mechanism for use in a multi-thread environment supporting self-modifying code in which modifications to the code are made at runtime. The locking mechanism having associated helper code accessed by a call from the first instruction address in the code block. The helper code calculating the binary encoding for the call instruction and using an atomic compare and exchange instruction to compare the calculated binary encoding with the actual contents of the first instruction address. Where there is a match, a self loop instruction is written to the first instruction address to lock the specified code block for subsequent threads. The helper code contains instructions to resolve the references in the specified block. The last such instruction is an atomic store operation to replace the self loop instruction at the first instruction address with the appropriate modified instruction.

Abstract: A method, apparatus, and computer instructions are provided for transforming Java Native Interface function calls to constants, internal just-in-time compiler operations or simpler intermediate representation. A compiler generates a plurality of intermediate representations for a plurality of native interface function calls. During inlining of native code, matching is performed on each native function call (against this list) and a list of native interface function calls is generated. For each native interface function call, a JIT call transformer attempts to replace the native interface function call with a constant, internal just-in-time compiler operation or a simpler intermediate representation depending on the type of native interface function call.

Abstract: A method, apparatus, and computer instructions are provided for inlining native functions into compiled Java code. A conversion engine is provided by the present invention for converting the intermediate representation of native functions to the just-in-time (JIT) compiler's intermediate representation. With the converted intermediate representation, an inliner recursively inlines the converted JIT compiler's intermediate representation into the native callsite to remove the need of invoking the native function and subsequent native calls made by the function. The inlining process continues until either a call to an opaque function is encountered or until a JIT compiler intermediate representation growth limits are reached. The inliner also replaces calls to most native functions that are non-inlineable or opaque with calls to synthesized native functions that provide access to native libraries containing implementations of the original non-inlineable calls.

Abstract: Under the present invention, a locking primitive associated with a shared data object is automatically transformed to allow multiple read-only locks if certain conditions are met. To this extent, when a read-only lock on a shared data object is desired, a thread identifier of an object header lock word (hereinafter “lock word”) associated with the shared data object is examined to determine if a read-write lock on the shared data object already exists. If not, then the thread identifier is set to a predetermined value indicative of read-only locks, and a thread count in the lock word is incremented. If another thread attempts a read-only lock, the thread identifier will be examined for the predetermined value. If it is present, the thread count will be incremented again, and a second read-only lock will be simultaneously established.

Abstract: Virtual function calls in hybrid compiled and interpreted computer programming environments are carried out efficiently by dual virtual function tables. Each class object generated is provided with a compiled virtual function table and an interpreted virtual function table. Each table is symmetrically structured and contiguous with the class object. Calls from an interpreted function access the interpreted virtual function table. Entries in that table point to function data structures which provide for the interpretation of the called function, or for transfer to execution of a compiled version of the called function. Calls from a compiled function access the compiled virtual function table. Entries in the compiled virtual function table point to either executable code representing the called function, or to transition code for transition to the interpreter to interpret the called function.

Abstract: Under the present invention, program code is examined (statically or dynamically) for characteristics indicative of a potential to generate multiple threads. If none are found, single threaded optimization(s) such as desynchronization, optimization of globals, etc., can be implemented. In addition, if the program code is later revealed to have the potential to generate multiple threads, the single threaded optimization(s) can be corrected to avoid incorrect execution.

Abstract: A method, system and apparatus for barrier synchronization using distributed counters and a centralized sensor. The system can include multiple distributed counters coupled to corresponding application processes in a computing application. The barrier synchronization system further can include a centralized sensor coupled for observation by the application processes. Preferably, the application processes can be separate threads of execution in the computing application. The barrier synchronization centralized sensor yet further can be managed by a designated master one of the application processes. Moreover, preferably the system further can include a backup sensor coupled for observation by the application processes and managed by the designated master one of the application processes.

Abstract: A compiler component for the generation of an optimal instruction sequence, the sequence including a compile-time unresolved reference to be resolved at runtime. The compiler generating a snippet list with entries corresponding to snippets defined for instructions including unresolved compile-time references. A runtime helper routine being defined for resolving references at runtime. For each instruction with an unresolved reference, generating a snippet including data for identifying the reference and for permitting resolution of the reference at runtime by the runtime helper routine. The snippet also including a copy of the instruction containing the unresolved reference. The location in the compiled code for the unresolved instruction being written with a call instruction to the snippet. The runtime helper being invoked by the snippet at runtime to resolve the references and to copy the unresolved code copy to the compiled code, with the references resolved.

Abstract: Virtual function calls in hybrid compiled and interpreted computer programming environments are carried out efficiently by dual virtual function tables. Each class object generated is provided with a compiled virtual function table and an interpreted virtual function table. Each table is symmetrically structured and contiguous with the class object. Calls from an interpreted function access the interpreted virtual function table. Entries in that table point to function data structures which provide for the interpretation of the called function, or for transfer to execution of a compiled version of the called function. Calls from a compiled function access the compiled virtual function table. Entries in the compiled virtual function table point to either executable code representing the called function, or to transition code for transition to the interpreter to interpret the called function.

Abstract: A locking mechanism for use in a multi-thread environment supporting self-modifying code in which modifications to the code are made at runtime. The locking mechanism having associated helper code accessed by a call from the first instruction address in the code block. The helper code calculating the binary encoding for the call instruction and using an atomic compare and exchange instruction to compare the calculated binary encoding with the actual contents of the first instruction address. Where there is a match, a self loop instruction is written to the first instruction address to lock the specified code block for subsequent threads. The helper code contains instructions to resolve the references in the specified block. The last such instruction is an atomic store operation to replace the self loop instruction at the first instruction address with the appropriate modified instruction.

Abstract: A compiler component for the generation of an optimal instruction sequence, the sequence including a compile-time unresolved reference to be resolved at runtime. The compiler generating a snippet list with entries corresponding to snippets defined for instructions including unresolved compile-time references. A runtime helper routine being defined for resolving references at runtime. For each instruction with an unresolved reference, generating a snippet including data for identifying the reference and for permitting resolution of the reference at runtime by the runtime helper routine. The snippet also including a copy of the instruction containing the unresolved reference. The location in the compiled code for the unresolved instruction being written with a call instruction to the snippet. The runtime helper being invoked by the snippet at runtime to resolve the references and to copy the unresolved code copy to the compiled code, with the references resolved.

Abstract: In the field of mixed 16-bit and 32-bit code, a method and mechanism are provided to implement alterations in the dynamic portion of memory containing the data objects used by code in the 16-bit environment so that such data is accessible to code from the 32-bit environment. The code necessary to implement the method is generated automatically by an enhanced compiler on identifying 16-bit linkage in the 32-bit code. Once the data objects in the stack are accesible to the 32-bit code, a function in the 16-bit code can successfully call a function in 32-bit code.

Abstract: In the field of mixed 16-bit and 32-bit code, a method and mechanism are provided to implement alterations in the dynamic portion of memory containing the data objects used by code in the 32-bit environment so that such data is accessible to code from the 16-bit environment. Once the data objects in the stack are accesible to the 16-bit code, a function in the 32-bit code can successfully call a function in 16-bit code.