Systems and methods for adaptive integration of hardware and software lock elision techniques

• US 9,183,043 B2
• Filed: 04/16/2014
• Issued: 11/10/2015
• Est. Priority Date: 07/16/2013
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: Dice, David, Kogan, Alex, Lev, Yosef, Merrifield, Timothy M., Moir, Mark S.
• Primary Examiner(s): Nguyen, Van
• Application Number:
  US14/254,758
• Publication Number:
  US 20150026688A1
• Time in Patent Office: 573 Days
• US Class Current: 1/1
• CPC Class Codes: G06F 9/467 Transactional memory G06F9/528 takes precedence
• CPC Class Codes: G06F 9/468 Specific access rights for resources, e.g. using capability register
• CPC Class Codes: G06F 9/4843 by program, e.g. task dispatcher, supervisor, operating system
• CPC Class Codes: G06F 9/4881 Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
• CPC Class Codes: G06F 9/5022 Mechanisms to release resources
• CPC Class Codes: G06F 9/528 by using speculative mechanisms

Abstract

Particular techniques for improving the scalability of concurrent programs (e.g., lock-based applications) may be effective in some environments and for some workloads, but not others. The systems described herein may automatically choose appropriate ones of these techniques to apply when executing lock-based applications at runtime, based on observations of the application in the current environment and with the current workload. In one example, two techniques for improving lock scalability (e.g., transactional lock elision using hardware transactional memory, and optimistic software techniques) may be integrated together. A lightweight runtime library built for this purpose may adapt its approach to managing concurrency by dynamically selecting one or more of these techniques (at different times) during execution of a given application. In this Adaptive Lock Elision approach, the techniques may be selected (based on pluggable policies) at runtime to achieve good performance on different platforms and for different workloads.

Claims

1. A method, comprising:

performing by a computer;

beginning execution of a multithreaded application;

while executing the application, a thread of the application encountering a critical section of code in the application that is associated with a lock, wherein when the lock is held by a thread, other threads are prevented from entering the critical section;

determining a context in which the critical section was encountered;

determining a policy that is applicable to the determined context, wherein the policy is usable in determining which of a plurality of integrated mechanisms for executing the critical section without acquiring the lock is to be employed in attempting to execute the critical section;

selecting one of the plurality of integrated mechanisms, dependent on the determined policy; and

the thread attempting to execute the critical section using the selected one of the plurality of integrated mechanisms.

2. The method of claim 1, wherein said selecting comprises determining whether to attempt to execute the critical section using hardware transactional memory or to execute the critical section using an optimistic alternative code path.

3. The method of claim 1, wherein said determining the context is based, at least in part, on one or more of:

an environment or platform in which the application is executing;

availability or capability of hardware transactional memory support for executing the critical section using a hardware transaction;

concurrent use of hardware transactional memory by another thread in executing a critical section of code in the application that is associated with the lock;

availability of an optimistic alternative code path for the critical section;

concurrent use of an optimistic alternative code path by another thread in executing a critical section of code in the application that is associated with the lock;

or

potential concurrent use of an optimistic alternative code path by another thread in executing a critical section of code in the application that is associated with the lock.

4. The method of claim 3, wherein said determining the context comprises detecting an indication of concurrent use of an optimistic alternative code path by one or more other threads in executing a respective critical section of code in the application that is associated with the lock or potential concurrent use of an optimistic alternative code path by one or more other threads in executing a respective critical section of code in the application that is associated with the lock.

5. The method of claim 4,

wherein said selecting comprises determining that the thread should attempt to execute the critical section using hardware transactional memory;

and

wherein said attempting to execute the critical section comprises, prior to attempting to execute the critical section using hardware transactional memory, waiting for each of the one or more other threads to complete execution of its respective critical section using an optimistic alternative code path.

6. The method of claim 1,

wherein the method further comprises, prior to said beginning execution:

receiving input for use in instrumenting the application, wherein the input identifies a context in which the critical section will be encountered, specifies a condition usable in determining the context in which the critical section will be encountered, or indicates availability of an optimistic alternative code path for executing the critical section; and

instrumenting the application according to the received input; and

wherein said determining the context is dependent on execution of the application as instrumented.

7. The method of claim 1, wherein the method further comprises, prior to said beginning execution:

receiving input for use in instrumenting the application, wherein the input identifies a conflict region within the critical section, wherein the conflict region comprises program instructions that, when executed, are capable of causing a conflict with another thread that is executing a critical section of code in the application that is associated with the lock.

8. The method of claim 1, further comprising:

collecting, during said executing the application, information characterizing said executing, wherein the collected information comprises one or more of;

information characterizing the workload of the application;

information indicating a number of times that execution of each critical section of code in the application was attempted;

information indicating a number or percentage of times that a critical section of code in the application was successfully executed using each of the plurality of integrated mechanisms;

information indicating a number or percentage of times that execution of a critical section of code in the application was attempted using each of the plurality of integrated mechanisms;

or

information indicating an amount of time spent in attempting to execute a critical section of code in the application using each of the plurality of integrated mechanisms.

9. The method of claim 8, wherein said collecting information is performed on a per-lock basis, a per-critical-section basis, a per-context basis, or per lock-context pair.

10. The method of claim 8, wherein at least one of said determining a context or said determining a policy is dependent on the collected information or is performed automatically in response to said collecting.

11. The method of claim 8,

wherein the method further comprises, prior to said beginning execution:

receiving input for use in instrumenting the application;

instrumenting the application according to the received input; and

wherein the granularity at which the information is collected during said executing the application, as instrumented, is dependent on the received input.

12. The method of claim 8,

wherein the selected policy is an adaptive policy;

and

wherein said selecting one of the plurality of integrated mechanisms, dependent on the determined policy, is further dependent on the collected information.

13. The method of claim 1, further comprising:

in response to failing to successfully execute the critical section using the selected one of the plurality of integrated mechanisms, attempting to execute the critical section using a different one of the plurality of integrated mechanisms.

14. The method of claim 1, further comprising:

in response to failing to successfully execute the critical section using the selected one of the plurality of integrated mechanisms;

acquiring the lock;

executing the critical section while holding the lock; and

releasing the lock.

15. A system, comprising:

one or more processor cores; and

a memory coupled to the one or more processor cores and storing program instructions that when executed on the one or more processor cores cause the one or more processor cores to perform;

beginning execution of a concurrent application;

while executing the application, a process of the application encountering a critical section of code in the application that is associated with a lock, wherein when the lock is held by a process, other processes are prevented from entering the critical section;

determining a context in which the critical section was encountered;

determining a policy that is applicable to the determined context, wherein the policy is usable in determining which of a plurality of integrated mechanisms for executing the critical section without acquiring the lock is to be employed in attempting to execute the critical section;

selecting one of the plurality of integrated mechanisms, dependent on the determined context or the determined policy; and

the process attempting to execute the critical section using the selected one of the plurality of integrated mechanisms.

16. The system of claim 15, wherein at least one of said determining a context, said determining a policy, or said selecting one of the plurality of integrated mechanisms is based, at least in part, on one or more of:

an environment or platform in which the application is executing;

availability or capability of hardware transactional memory support for executing the critical section using a hardware transaction;

concurrent use of hardware transactional memory by another process in executing a critical section of code in the application that is associated with the lock;

availability of an optimistic alternative code path for the critical section;

concurrent use of an optimistic alternative code path by another process in executing a critical section of code in the application that is associated with the lock;

or

potential concurrent use of an optimistic alternative code path by another process in executing a critical section of code in the application that is associated with the lock.

17. The system of claim 15,

wherein when executed on the one or more processor cores, the program instructions cause the one or more processor cores to perform collecting, during said executing the application, information characterizing said executing, wherein the collected information comprises one or more of:

information characterizing the workload of the application;

information indicating a number of times that execution of each critical section of code in the application was attempted;

information indicating a number or percentage of times that a critical section of code in the application was successfully executed using each of the plurality of integrated mechanisms;

information indicating a number or percentage of times that execution of a critical section of code in the application was attempted using each of the plurality of integrated mechanisms;

or

information indicating an amount of time spent in attempting to execute a critical section of code in the application using each of the plurality of integrated mechanisms; and

wherein at least one of said determining a context, said determining a policy, or said selecting one of the plurality of integrated mechanisms is dependent on the collected information.

18. A non-transitory, computer-readable storage medium storing program instructions that when executed on one or more computers cause the one or more computers to perform:

beginning execution of a multithreaded application;

while executing the application, a thread of the application encountering a critical section of code in the application that is associated with a lock, wherein when the lock is held by a thread, other threads are prevented from entering the critical section;

determining a context in which the critical section was encountered;

determining a policy that is applicable to the determined context, wherein the policy is usable in determining which of a plurality of integrated mechanisms for executing the critical section without acquiring the lock is to be employed in attempting to execute the critical section;

selecting one of the plurality of integrated mechanisms, dependent on the determined context or the determined policy; and

the thread attempting to execute the critical section using the selected one of the plurality of integrated mechanisms.

19. The non-transitory, computer-readable storage medium of claim 18, wherein at least one of said determining a context, said determining a policy, or said selecting one of the plurality of integrated mechanisms is based, at least in part, on one or more of:

an environment or platform in which the application is executing;

availability or capability of hardware transactional memory support for executing the critical section using a hardware transaction;

concurrent use of hardware transactional memory by another thread in executing a critical section of code in the application that is associated with the lock;

availability of an optimistic alternative code path for the critical section;

concurrent use of an optimistic alternative code path by another thread in executing a critical section of code in the application that is associated with the lock;

or

potential concurrent use of an optimistic alternative code path by another thread in executing a critical section of code in the application that is associated with the lock.

20. The non-transitory, computer-readable storage medium of claim 18,

wherein when executed on the one or more computers, the program instructions cause the one or more processor cores to perform collecting, during said executing the application, information characterizing said executing, wherein the collected information comprises one or more of:

information characterizing the workload of the application;

information indicating a number of times that execution of each critical section of code in the application was attempted;

information indicating a number or percentage of times that a critical section of code in the application was successfully executed using each of the plurality of integrated mechanisms;

information indicating a number or percentage of times that execution of a critical section of code in the application was attempted using each of the plurality of integrated mechanisms;

or

information indicating an amount of time spent in attempting to execute a critical section of code in the application using each of the plurality of integrated mechanisms; and

wherein at least one of said determining a context, said determining a policy, or said selecting one of the plurality of integrated mechanisms is dependent on the collected information.