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: Techniques for causing a compiler to organize code pertaining to data that is not constant, but that is unlikely to change except in relatively infrequent situations, in an improved manner. A class containing data that may have more than one value, but which will have a particular value in the typical case, is now split into two parts, a first class which uses the more-likely data value as a constant, and a second class (designed as a subclass of the first class) that uses the data value as a variable capable of having either the more-likely value or other, less-likely values. The compiler generates assembly code comprising instructions pertaining to the more-likely data value, and also generates assembly code capable of processing the less-likely data values. This latter code, however, is initially unreachable. The compiler-generated assembly code will be programmatically patched, at run time, if any of the less-likely data values occur, thereby dynamically making the code reachable.

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: An improved method and system for acquisition and release of locks within a software program is disclosed. In an exemplary embodiment, a lock within a loop is transformed by relocating acquisition and release instructions from within the loop to positions outside the loop. This may significantly decrease unnecessarily lock acquisition and release during execution of the software program. In order to avoid contention problems which may arise from acquiring and keeping a lock on an object over a relatively long period of time, a contention test may be inserted into the loop. Such a contention test may temporarily release the lock if another thread in the software program requires access to the locked object.