Code section optimization by removing memory barrier instruction and enclosing within a transaction that employs hardware transaction memory

A code section of a computer program to be executed by a computing device includes memory barrier instructions. Where the code section satisfies a threshold, the code section is modified, by enclosing the code section within a transaction that employs hardware transactional memory of the computing device, and removing the memory barrier instructions from the code section. Execution of the code section as has been enclosed within the transaction can be monitored to yield monitoring results. Where the monitoring results satisfy an abort threshold corresponding to excessive aborting of the execution of the code section as has been enclosed within the transaction, the code section is split into code sub-sections, and each code sub-section enclosed within a separate transaction that employs the hardware transactional memory. Splitting the code section sections and enclosing each code sub-section within a separate transaction can decrease occurrence of the code section aborting during execution.

BACKGROUND

Computer code includes instructions that are organized in a particular order, and which are executed by a processor, such as a central processing unit (CPU), to perform desired functionality. It is usually presumed by the developer of the computer code that the instructions thereof will be executed in the order in which the instructions are presented. However, some types of processors and compilers optimize computer code to improve execution performance, and this optimization can result in out-of-order execution of the instructions.

While generally such out-of-order execution is not problematic, it can cause unpredictable behavior, particularly with respect to load and store instructions that are executed in relation to memory locations. If the contents of a memory location are loaded before desired contents are stored at this memory location, when it is expected that the desired contents will be stored before they are subsequently loaded, problems can arise such that the computer code does not perform its desired functionality. Therefore, processors and compilers can include mechanisms by which to enforce ordering constraints in the executions of instructions within computer code.

One such mechanism is a memory barrier instruction, which is also referred to as a memory barrier instruction, a membar, a memory fence, or a fence instruction. A memory barrier instruction prohibits instructions, such as load and store instructions, located after the memory barrier from being executed prior to instructions, such as load and store instructions, located before the memory barrier. For example, if a store instruction has to be executed prior to a load instruction, then a memory barrier instruction can be inserted somewhere between the store instruction and the load instruction. As such, unpredictable behavior in computer code execution can be avoided.

SUMMARY

A method of an embodiment of the invention includes receiving, by a processor, a code section of a computer program to be executed by a computing device. The code section includes one or more memory barrier instructions. The method includes determining, by the processor, whether the code section satisfies one or more thresholds. The method includes, responsive to determining that the code section satisfies the thresholds, modifying the code section. The code section is modified by the processor enclosing the code section within a transaction that employs hardware transactional memory of the computing device, such that an entirety of the code section is executed or none of the code section is executed. The code section is also modified by the processor removing the memory barrier instructions from the code section.

A computer program product of an embodiment of the invention includes a computer-readable storage medium having computer-readable code embodied therein. The computer-readable code is executable by a processor to modify a code section of a computer program to be executed by a computing device. The code section includes one or more memory barrier instructions. Modifying the code section includes enclosing the code section within a transaction that employs hardware transactional memory of the computing device, such that an entirety of the code section is executed or none of the code section is executed. Modifying the code section also includes removing the memory barrier instructions from the code section.

A system of an embodiment of the invention includes a processor, a storage device, and a software component. The storage device is to store a code section of a computer program to be executed by a computing device. The code section includes one or more memory barrier instructions. The software component is executable by the processor to modify the code section. The software component modifies the code section by enclosing the code section within a transaction that employs hardware transactional memory of the computing device, such that an entirety of the code section is executed or none of the code section is executed. The software component also modifies the code section by removing the memory barrier instructions from the code section.

DETAILED DESCRIPTION

As noted in the background section, a memory barrier instruction is a mechanism to enforce the order of execution of instructions, particularly load and store instructions, within computer code. Instructions within the computer code before a memory barrier instruction are guaranteed to be executed before instructions within the computer code after the memory barrier instruction. Out-of-order execution can still occur among the instructions before the memory barrier instruction, as well as among the instructions after the memory barrier instruction, but instruction execution cannot cross the memory barrier.

A problem with memory barrier instructions, however, is that computationally they are typically very expensive to process. As such, performance degradation of the resulting computer code can result. For instance, execution of the computer code may degrade in performance, and/or compilation of the computer code may degrade in performance.

Techniques disclosed herein reduce usage of memory barrier instructions within computer code to avoid the performance degradation associated with their usage. Most generally, computer code that includes one or more memory barrier instructions is enclosed within a transaction that employs hardware transactional memory of a processor of a computing device, and the memory barrier instructions therein removed. Such hardware transactional memory ensures that load and store instructions within the computer code are executed atomically. That is, it is guaranteed that all the instructions (or specifically just load and store instructions) within the computer code are executed in order, or none of the instructions are executed. Where employing hardware transactional memory is less performance degrading than using memory barrier instructions is, performance can thus be improved.

FIG. 1shows an example code section100of a computer program to be executed by a processor of a computing device, according to an embodiment of the invention. The code section100includes a number of instructions102A and a number of instructions102B, which are collectively referred to as the instructions102. The code section100further includes a memory barrier instruction104. The instructions102A include a load instruction to load the contents of memory location A, and a store instruction to store desired contents into memory location B. The instructions102B include a load instruction to load the contents of memory location B, and a store instruction to store desired contents into memory location A.

Since the memory barrier instruction104is located between the instructions102A and102B, it is guaranteed that all the instructions102B (or just the load and store instructions thereof) will not be executed prior to the instructions102A (or just prior to the load and store instructions thereof). For example, it is guaranteed that the contents of memory location A will be loaded pursuant to the load instruction within the instructions102A before desired contents are stored within memory location A pursuant to the store instruction within the instructions102B. Likewise, it is guaranteed that desired contents of memory location B will be stored pursuant to the store instruction within the instructions102A before contents of memory location B are loaded pursuant to the load instruction within the instructions102B.

FIG. 2shows a method200for optimizing a code section that includes one or more memory barrier instructions so that execution and/or compilation performance is not degraded as a result of these memory barrier instructions, according to an embodiment of the invention. The method200is exemplarily described in relation to the example code section100ofFIG. 1. However, more generally, the method200can be performed in relation to any code section that includes one or more memory barrier instructions. The method200can be performed by a processor of a computing device, which may be the same processor and/or computing device that is to execute the code section100, or a different processor and/or computing device.

The method200receives the code section100of a computer program, where the code section100includes one or more memory barrier instructions, such as the memory barrier instruction104(202). The method200determines whether the code section100satisfies one or more thresholds (204). Threshold satisfaction is assessed to determine whether the code section100should be enclosed in a transaction and have its memory barrier instruction104removed. One threshold can be that an associated processing cost of employing hardware transactional memory of the computing device that is to execute the code section100is less than an associated processing cost of executing the memory barrier instruction104within the code section100.

More specifically, executing the memory barrier instruction104has an associated processing cost. This processing cost may be the length of time needed to execute the code section100including the memory barrier instruction104as compared to the length of time needed to execute the code section100if the memory barrier instruction104were not present. Likewise, using the hardware transactional memory in lieu of the memory barrier instruction104has an associated processing cost. This processing cost may be the length of time needed to execute the code section100using the hardware transactional memory as compared to the length of time needed to execute the code section100if the hardware transactional memory were not employed (and the memory barrier instruction104not present). If the former processing cost is greater than the latter processing cost, then removal of the memory barrier instruction104from the code section100and utilization of the hardware transactional memory instead may be appropriate.

A second threshold can be that an estimated transaction size of a transaction enclosing the code section100to utilize the hardware transactional memory is less than a memory size of the hardware transactional memory. The hardware transactional memory of the processor and/or of the computing device including this processor that is to execute the code section100has a finite amount of memory. Enclosing the code section100within a transaction so that the instructions102are executed atomically results in a transaction having an (estimated) transaction size.

If this estimated transaction size is greater than the memory size of the hardware transactional memory, then the transaction will likely not be performed or executed correctly. Rather, an out-of-(hardware transactional) memory error may be thrown during performance or execution, resulting in the transaction being prematurely aborted instead of properly finishing. Therefore, utilization of the hardware transactional memory may be appropriate just if the estimated transaction size of the transaction-enclosed code section100is less than the memory size of the hardware transactional memory that will be used.

The estimated transaction size of the transaction can be determined based on the number of load and store instructions within the code section100enclosed by the transaction. The estimated transaction size can be improved (i.e., made more accurate) by not duplicatively counting load and store instructions to the same memory location. For example, if there are five such instructions relating to the same memory location, then the transaction size is estimated based on just one of these instructions, and not all five. The load and store instructions can be analyzed to determine whether they refer to the same memory location by using alias analysis techniques, for instance.

A third threshold can be that the code section100does not include any instructions102that call functions outside of the code section100. Outside function calls within the code section100can cause the transaction in which the code section100is enclosed to abort, due to, for instance, an out-of-(hardware transactional) memory error. Therefore, utilization of the hardware transactional memory may be appropriate just if the code section100does not include any calls to functions that are external to the code section100.

If the code section100does not satisfy the specified threshold(s) (206), then the method200is finished (208), and the code section100is not optimized to reduce performance degradation resulting from the memory barrier instruction104. However, if the code section100satisfies the specified threshold(s) (206), then the method200optimizes the code section100to reduce performance degradation resulting from the memory barrier instruction104. As an initial matter, execution of the code section100may be monitored, or profiled, and revised (210), so that the code section100is better optimized for subsequent enclosure within a transaction.

Monitoring or profiling of the code section100while the code section100still includes the memory barrier instruction104yields what are referred to herein as monitoring results. The monitoring results can include a more accurate estimation of the associated processing costs in executing the memory barrier instruction104, as well as a more accurate estimation of the transaction size of the transaction needed to enclose the code section100were the memory barrier instruction104removed. The monitoring results can include the likelihood that memory conflicts will result when using a transaction, causing the transaction to prematurely abort instead of completing successfully. When a transaction prematurely aborts, the processor that provides the hardware transactional memory in question may save the reason why the transaction so aborted in an architectural register thereof, or within a special area within a storage device.

These monitoring results can be used in a number of different ways. First, the code section100can be revised to reduce the likelihood, for instance, that a transaction in which the code section100is enclosed will abort. For example, the code section100may be split into code sub-sections, as is described in detail later in the detailed description, in relation to parts224and226of the method200. Second, it may be determined that in actuality the code section100does not satisfy the specified threshold(s), such that the code section100is indeed not a suitable candidate for enclosing within a transaction.

Other dynamic optimizations may be performed on the code section100in part210to decrease the resulting processing cost of enclosing the code section100within a transaction in lieu of using the memory barrier instruction104. As one example, loops of instructions within the code section100may be unrolled and tiled. Loop unrolling and tiling packs multiple iterations of a loop into a single transaction. This can help ensure that the resulting estimated transaction size does not exceed the hardware transactional memory size.

The code section100is enclosed within a transaction employs the hardware transactional memory (212), and the memory barrier instructions, such as the memory barrier instruction104, removed from the code section (214). Enclosing the code section100can include adding three instructions to the code section100. A transaction-start instruction can be added prior to the first instruction within the code section100. A transaction-end instruction can be added after the last instruction within the code section100, and a transaction-abort instruction can replace one or more instructions102within the code section100. The transaction-end instruction corresponds to non-exceptional normal exit from the code section100—i.e., where the code section100is completely and properly executed, without throwing an exception.

By comparison, a transaction-abort instruction can replace the instructions102within the code section100that handle exceptional and abnormal exit from the code section100—i.e., where the code section100is not completely and properly executed, and instead throws an exception. A transaction-abort instruction can be used to replace those instructions102that are rarely executed, to reduce the size of the code section100. In this latter case, the monitoring results may indicate, for instance, which of the instructions102are rarely executed.

FIG. 3shows the code section100ofFIG. 1after parts212and214of the method200have been performed, according to an embodiment of the invention. InFIG. 3, the memory barrier instruction104ofFIG. 1is no longer present within the code section100, pursuant to part214. Furthermore, three transaction-related instructions302A,302B, and302C, collectively referred to as the transaction-related instructions302, have been added to the code section100, pursuant to part212. Via addition of the transaction-related instructions302to the code section100, it is said that the code section100has been enclosed within a transaction that employs the hardware transactional memory so that at least some of the instructions102are executed in an atomic manner.

The transaction-related instruction302A is a transaction-start instruction that is added prior to the first instruction of the code section100, and thus before the instructions102A. The transaction-related instruction302B is a transaction-end instruction that is added after the last instruction of the code section100, and thus after the instructions102B. The transaction-related instruction302C is a transaction-abort instruction that replaces one or more of the instructions102(specifically one or more of the instructions102B).

Referring back toFIG. 2, once the memory barrier instruction104has been removed from the code section100, and the code section100has been enclosed within a transaction, execution of the resulting code section100can be monitored (216). Monitoring of the code section100after enclosure within a transaction and after removal of the memory barrier instruction104yields what are also referred to herein as monitoring results. However, these monitoring results should not be confused with those described in relation to part210above, which pertain to monitoring of the code section100prior to enclosure of the code section100within a transaction and when the code section100still includes the memory barrier instruction104.

The monitoring results can indicate how often the code section100has thrown an exception when executed, and thus how often the code section100is not executing completely and properly. The monitoring results can further indicate why the code section100has had its execution aborted, each time such aborting occurs. An abort threshold is said to correspond to excessive aborting of the execution of the code section100as enclosed within a transaction. The abort threshold may encompass the number, frequency, and/or type of this aborting, against which the monitoring results are compared to determine whether the code section100should be optimized further, to decrease the occurrence of the code section100aborting during execution. As one example, if the code section100aborts a minimum number of times at a great enough frequency, and/or for any of one or more particular reasons, then the code section100is a candidate for additional optimization.

If the monitoring results do not satisfy the specified abort threshold (220), then the method200is finished (222), and the code section100is not optimized further. However, if the monitoring results satisfy the specified abort threshold (220), then the method200optimizes the code section100further to decrease the occurrence of the code section100aborting when executed. One such optimization includes splitting the code section100into a number of code sub-sections (224), and enclosing each code sub-section within its own separate transaction (226). Instead of there being an overarching single transaction that encompasses the entirety of the code section100, therefore, there are a number of separate transactions that each encompass a portion, or sub-section, of the code section100. The manner by which such splitting and re-enclosure is achieved can be performed in accordance with why the code section100itself is excessively aborting during execution, as is now described in detail with reference to two examples.

First, the monitoring results may indicate that a primary reason why the execution of the code section100as enclosed within a transaction is excessively aborting is that the actual transaction size of this transaction is (routinely) exceeding the memory size of the hardware transactional memory by which the transaction is effectuated. Although the method200may compare an estimated transaction size against the memory size of the hardware transactional memory in part204, and enclose the code section100within a transaction just if this threshold is satisfied per part206, the actual transaction size can in some cases be larger than the estimated transaction size. In such cases, the primary reason why execution of the transaction-enclosed code section100excessively aborts may therefore be that the actual transaction size is larger than the memory size of the hardware transactional memory.

In this first example, the code section100is split into code sub-sections such that all the instructions102of the code section100are included within the code sub-sections. Stated another way, each and every instruction102is included within one of the code sub-sections, and thus within one of the separate transactions that enclose the code sub-sections. There is no instruction102that is not part of the code sub-sections in this first example, and thus there is no instruction102that is not within one of the separate transactions that enclose the code sub-sections. Because the transactions enclosing the code sub-sections are smaller in size than the original single transaction encompassing the code section100in its entirety, the likelihood that an out-of-memory exception will be thrown in the future is reduced.

FIG. 4shows the code section100ofFIG. 3after parts224and226of the method200have been performed in accordance with this first example, according to an embodiment of the invention. InFIG. 4, the entirety of the code section100is not enclosed within a single transaction, such that the transaction-related instructions302have been removed from the code section100inFIG. 4. The code section100has been split into two code sub-sections406A and406B, which are collectively referred to as the code sub-sections406. The code sub-section406A includes some instructions102A′ of the code section100, whereas the code sub-section406B includes the remaining instructions102B′ of the code section100. As such, all the instructions102of the code section100are part of the code sub-sections406, and there is no instruction402that is not part of one of the code sub-sections406.

The instructions102are delineated as the instructions102A′ and102B′ inFIG. 4to denote that, although the instructions102A′ and102B′ represent all the instructions102of the code section100, the instructions102A′ do not necessarily correspond to the instructions102A ofFIG. 1and the instructions102B′ do not necessarily correspond to the instructions102B ofFIG. 1. That is, the code section100is not necessarily split so that the code sub-section406A includes exactly just the instructions102A and so that the code sub-section406B includes exactly just the instructions102B. For instance, the instructions102A′ may include all the instructions102A and some of the instructions102B, or the instructions102B′ may include all the instructions102B and some of the instructions102A.

The code sub-section406A is enclosed within its own separate transaction, via the addition of three transaction-related instructions402A,402B, and402C, which are collectively referred to as the transaction-related instructions402, and which are a transaction-start instruction, a transaction-end instruction, and a transaction-abort instruction, respectively. Likewise, the code sub-section406B is enclosed within its own separate transaction, via the addition of three transaction-related instructions404A,404B, and404C, which are collectively referred to as the transaction-related instructions404, and which are also a transaction-start instruction, a transaction-end instruction, and a transaction-abort instruction, respectively. The transactions enclosing the code sub-sections406inFIG. 4are each smaller in transaction size than the single transaction enclosing the entire code section100inFIG. 3. As such, the likelihood that execution of the code section100will abort in the future due to out-of-(hardware transactional) memory exceptions is reduced.

Second, the monitoring results may indicate that a primary reason why the execution of the code section100as enclosed within a transaction is excessively aborting is that a particular instruction102of the code section100is causing a memory conflict. For instance, if the particular instruction102relates to a shared variable, the variable may be written to while the code section100is being executed atomically due to its enclosure within the transaction. In this case, execution of the transaction aborts.

In this second example, the code section100is again split into code sub-sections. However, not all the instructions102of the code section100are included within the code sub-sections. Specifically, the particular instruction102is not included within any code sub-section, and thus is not within any of the separate transactions that enclose the code sub-sections. Because the particular instruction102causing the memory exception is no longer part of a transaction, the likelihood that a memory except will be thrown in the future is reduced.

All the other instructions102except for such a particular instruction102causing a memory conflict can, however, be included within the code sub-sections, and thus within the separate transactions that enclose the code sub-sections. For instance, one of the code sub-sections into which the code section100has been split can be located immediately prior to the particular instruction102causing the memory conflict. Another of the code sub-sections into which the code section100has been split can be located immediately after the particular instruction102causing the memory conflict.

FIG. 5shows the code section100ofFIG. 3after parts224and226of the method200have been performed in accordance with this second example, according to an embodiment of the invention. InFIG. 5, the entirety of the code section100is not enclosed within a single transaction, such that the transaction-related instructions302have been removed from the code section100inFIG. 5, as inFIG. 4. The code section100has been split into two code sub-sections506A and506B, which are collectively referred to as the code sub-sections506. The code sub-section506A includes some instructions102A″ of the code section100, whereas the code sub-section506B includes other instructions102B″ of the code section100. The only instruction102of the code section100that is not part of either code sub-section406is the particular instruction102C″, which is the instruction102that is causing a memory conflict.

The instructions102are delineated as the instructions102A″,102B″, and102C″ inFIG. 5to denote that, although the instructions102A″,102B″, and102C″ represent all the instructions102of the code section100, the instructions102A″ do not necessarily correspond to the instructions102A ofFIG. 1and the instructions102B″ do not necessarily correspond to the instructions102B ofFIG. 1. That is, the code section100is not necessarily split so that the code sub-section506A includes exactly just the instructions102A or that the code sub-section506B includes exactly just the instructions102B. Furthermore, the instructions102A″ or102B″ have to differ from the instructions102A or102B, respectively, because the instruction102C″ is within the instructions102A or102B.

The code sub-section506A is enclosed within its own separate transaction, via the addition of three transaction-related instructions502A,502B, and502C, which are collectively referred to as the transaction-related instructions502, and which are a transaction-start instruction, a transaction-end instruction, and a transaction-abort instruction, respectively. Likewise, the code sub-section506B is enclosed within its own separate transaction, via the addition of three transaction-related instructions504A,504B, and504C, which are collectively referred to as the transaction-related instructions504, and which are also a transaction-start instruction, a transaction-end instruction, and a transaction-abort instruction, respectively. The transactions enclosing the code sub-sections506inFIG. 5do not include the instruction102C″, since as noted above the instruction102C″ is not part of either code sub-section506A or506B. As such, the likelihood that execution of the code section100will abort in the future due to a memory conflict is reduced.

As depicted inFIG. 5, the code sub-section506A is located immediately prior to the instruction102C″ causing the memory conflict. Similarly, the code sub-section506B is located immediately after the instruction102C″ causing the memory conflict. As such, inFIG. 5there is no instruction102, other than the instruction102C″ that is not within one of the code sub-sections506into which the code section100has been split.

FIG. 6shows a representative computing device600, according to an embodiment of the invention. The computing device600includes at least a processor602and a storage device604that stores at least an optimization component606, which is a software component. The processor602thus executes the optimization component606from the storage device604. The storage device604can be or include volatile memory, such as dynamic random-access memory, as well as non-volatile memory, such as flash memory or a hard disk drive, among other types of storage devices. Execution of the optimization component606causes the method200ofFIG. 2to be performed in relation to the code section100.

As depicted inFIG. 6, the storage device604also stores the code section100, and the computing device600also includes the hardware transactional memory608that supports execution of a transaction in an atomic manner, as has been described. In this implementation, then, the code section100is executed on the same computing device600on which the code section100is optimized by the optimization component606. However, more generally, there can be another computing device that includes the hardware transactional memory608and that executes the code section100. In this respect,FIG. 6thus shows a representative system, which is implemented over one or more computing devices.

In general, a computer program product includes a computer-readable medium on which one or more computer programs are stored. Execution of the computer programs from the computer-readable medium by one or more processors of one or more hardware devices causes a method to be performed. For instance, the method that is to be performed may be one or more of the methods that have been described above.

It is finally noted that, although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This application is thus intended to cover any adaptations or variations of embodiments of the present invention. As such and therefore, it is manifestly intended that this invention be limited only by the claims and equivalents thereof.