Reduced load balancing work stealing

Abstract

A method is provided that includes determining that a thief thread has attempted to steal work from a garbage collection (GC) owner queue. Additionally, the method includes determining that the number of tasks in the GC owner queue meets a predetermined threshold. Further, the method includes determining that the GC owner queue has a heavyweight task. The method also includes moving the heavyweight task to a head position in the GC owner queue.

Description

Technical Field

[0001] The present disclosure relates to load-balanced work stealing, and more particularly to reducing load-balanced work stealing.

[0002] Load balancing refers to the way a computer system distributes related work among multiple processes. In this way, load balancing can be useful in operating these systems more efficiently compared to operating a computer system without load balancing.

Summary of the Invention

[0003] Embodiments are disclosed for a method. The method includes determining that a sea thread attempts work stealing from a garbage collection (GC) owner queue. Additionally, the method includes determining that the number of tasks in the GC owner queue meets a predetermined threshold. Further, the method includes determining that the GC owner queue has heavyweight tasks. The method also includes moving a heavyweight task to the head position of the GC owner queue.

[0004] Furthermore, aspects of the present disclosure are directed to systems and computer program products having functions similar to the above-described functions of a computer-implemented method. The summary of the invention is not intended to represent every aspect, all implementations, and / or all embodiments of the present disclosure.

Brief Description of the Drawings

[0005] The drawings included in this application are incorporated herein and form a part of this specification. These illustrate embodiments of the present disclosure and, together with this description, serve to explain the principles of the present disclosure. The drawings are merely examples of specific embodiments and do not limit the present disclosure.

[0006]

Figure 1

[0007]

Figure 2A

Figure 2B

[0008]

Figure 3

[0009]

Figure 4

[0010]

Figure 5

[0011] Although the present disclosure is suitable for various modified forms and alternative forms, specific details thereof are shown by way of example in the drawings and will be described in detail. However, it should be understood that the present disclosure is not intended to be limited to the specific embodiments described. On the contrary, it is intended to cover all modified forms, equivalent forms, and alternative forms that fall within the scope of the present disclosure.

Modes for Carrying Out the Invention

[0012] As described above, load distribution can be a useful method for operating a computer system more efficiently. For example, load distribution is useful in work stealing, which is a garbage collection technique. Garbage collection refers to removing old and / or otherwise unused data from computer memory. Without garbage collection, computer storage can become cluttered and / or inefficiencies can be introduced in the way computer applications are executed or in the operation of the memory itself. Garbage collection involves multiple threads running in parallel and can reduce clutter and other potential inefficiencies, for example, by effectively deleting unused data in computer memory.

[0013] A garbage collection (GC) thread can track its work using a queue of tasks that it constructs when the garbage collection thread explores memory. However, when the garbage collection thread has no tasks, that garbage collection thread, for example, a scavenger thread, can "steal work" from the owner garbage collection thread that has unprocessed tasks in its respective queue. In other words, when the garbage collection thread has no tasks, this scavenger thread steals tasks from the owner thread's queue. In this way, the GC system distributes the load of garbage collection among the garbage collection threads. However, when performing work stealing in this way, a computational cost is incurred with respect to maintaining the integrity of the memory.

[0014] Accordingly, embodiments of the present disclosure can construct a garbage collection queue in a way that reduces the frequency with which a scavenger thread steals tasks from other garbage collection threads. In some embodiments, the garbage collection threads can place heavyweight tasks in their queues for the scavenger thread to steal. A heavyweight task can be a garbage collection task that has a relatively higher computational cost for execution compared to a relatively lightweight task. Accordingly, the scavenger thread may spend more time on the completion of the stolen heavyweight tasks than on the completion of the more lightweight tasks, thus causing a delay in the time between steals. In this way, embodiments of the present disclosure can reduce the frequency of steal attempts and improve the efficiency of load-balanced work stealing.

[0015] FIG. 1 is a block diagram of an exemplary computing system 100 for load-balanced work stealing reduction according to some embodiments of the present disclosure. The computing system 100 includes a memory 102 and a runtime environment (runtime) 104. The memory 102 can be a computer memory that stores data and computer instructions of computer applications. The memory 102 can include application objects 106 that can represent data and computer instructions of computer applications that are currently running or have completed execution on the computer system 100. In some scenarios, the application objects 106 can be represented as tree graphs that are described in more detail with respect to FIGS. 2A and 2B.

[0016] Referring back to FIG. 1, the runtime 104 can be a computing environment in which computer applications are executed. Further, the runtime 104 can provide a mechanism for the memory 102, how the application accesses variables, and passes parameters between applications, and manage how to interface with an operating system (not shown). The runtime 104 can include a virtual machine in an enterprise and / or open source platform such as the Java Virtual Machine (registered trademark).

[0017] According to some embodiments of the present disclosure, the runtime 104 can include a garbage collection manager 108 and a garbage collection thread 110. The runtime 104 can manage the memory 102 by using the garbage collection manager 108 and the garbage collection thread 110 to clean up the remaining application objects 106 in the memory. In this way, the runtime 104 helps to prevent the memory 102 from becoming cluttered and interfering with the performance of the applications running on the computer system 100. In this way, the garbage collection manager 108 can "collect the garbage" in the memory 102 by using the garbage collection thread 110. Further, the garbage collection thread 110 can distribute the workload of the garbage collection by performing work stealing.

[0018] During garbage collection processing, the garbage collection thread 110 may include a garbage collection (GC) owner thread 110-1 and a GC scavenger thread 110-2. As described above, when one of the garbage collection threads 110 completes a task in its queue 112, this thread can "steal" a task from another thread, such as the GC owner queue 112-1 of the GC owner thread 110-1, and execute the stolen task to help distribute the load of garbage collection. The garbage collection thread 110 that steals a task is thus referred to as the GC scavenger thread 110-2.

[0019] As described above, work stealing is computationally expensive and can reduce the efficiency of the computer system 100. Thus, in some embodiments of the present disclosure, the garbage collection manager 108 can reduce the frequency of work stealing and its associated costs by providing the GC scavenger thread 110-2 with stolen work, such as tasks, that take a relatively longer time to execute than other tasks. For example, when the GC scavenger thread 110-2 attempts to steal a task from the GC owner thread 110-1, the garbage collection manager 108 can place heavyweight tasks at the head of the queue for the GC scavenger thread 110-2 to steal. Thus, the GC scavenger thread 110-2 may spend more time executing heavyweight tasks than relatively lightweight tasks. In this way, when the GC scavenger thread 110-2 completes a stolen task, a longer delay occurs before the GC scavenger thread 110-2 steals another task from the GC owner thread 110-1. In this manner, the garbage collection manager 108 can reduce the number of load-distributing work steals performed by the GC scavenger thread 110-2. Thus, the garbage collection manager 108 can improve the performance of load-distributing work stealing in embodiments of the present disclosure.

[0020] FIG. 2A is a block diagram of exemplary GC owner queue 202-1 and GC thief queue 202-2 according to some embodiments of the present disclosure. GC owner queue 202-1 and GC thief queue 202-2 are also collectively referred to as GC queue 202. Queue 202 is represented as a cylinder containing alphabetically labeled circles, each representing a task for a named application object. These application objects can be examples of application objects 106 described with respect to FIG. 1. Referring again to FIG. 2A, GC owner queue 202-1 includes tasks "b", "c", "d", and "a" for each application object. In addition, queue 202 has arrows indicating pointers to the end (B) and start (T) of the queue. In addition, "push" and "pop" operations are represented by lines pointing to task "b" and from task "b", respectively. The push operation adds a new entry to the queue. In contrast, the pop operation removes an item from the queue. In this example, queue 202 represents an exemplary last-in first-out (LIFO) double-ended queue. Thus, the task at the end is the last task pushed onto queue 202. Thus, task "b" is at the end of the queue and is therefore the next task to be read and removed from GC owner queue 202-1. Further, task "b" is the next task to be executed by GC owner thread 110-1. In contrast, task "a" is at the start of the queue.

[0021] In contrast to the GC owner queue 202-1, the GC thief queue 202-2 has no tasks. The arrows for B and T respectively are shown separately for clarity. However, the end and the start of the GC thief queue 202-2 indicate the same empty entry. This example represents the time when the GC thief thread 110-2 may attempt to "steal" a task from the GC owner queue 202-1. This attempt at stealing is indicated by the line between the GC queues 202. In contrast to the pop operation that occurs at the start of the queue, work stealing involves an entry at the start of the queue, for example, task a. According to some embodiments of the present disclosure, garbage collection can place task "a" in response to a work stealing attempt if additional criteria are met. For example, the garbage collection manager 108 moves task "a" to the start of the queue if the number of entries in the GC owner queue 202-1 meets a predetermined threshold and that task "a" is a heavyweight task.

[0022] FIG. 2B is a block diagram of an exemplary GC queue 202 according to some embodiments of the present disclosure. In this example, the GC thief thread 110-2 has completed work stealing. Accordingly, task "a" is removed from the GC owner queue 202-1 and copied to the GC thief queue 202-2. Further, while the end of the GC owner queue 202-1 is still at task "B", the start of the GC owner queue 202-1 is now at task "d". With respect to the GC thief queue 202-2, the end and start arrows are shown separately for clarity but represent pointers to the same entry. Accordingly, task "a" is at the start and the end of the GC thief queue 202-2.

[0023] FIG. 3 is a block diagram of an exemplary memory 300 for load distribution work stealing reduction according to some embodiments of the present disclosure. As described above, the garbage collection thread 110 described with respect to FIG. 1 executes a garbage collection task. In some cases, the garbage collection task may involve parallel copy garbage collection (parallel copy GC). Parallel copy GC is used in both enterprise and open source JVMs, for example. Parallel copy GC may involve copying live application objects to a new space in memory. Live application objects may be application objects 106 that are still being used by a computer application. In contrast, non-active application objects are not copied to the new memory space. Non-active application objects may be application objects 106 that are no longer being used by a computer application. Since non-active application objects are not copied to the new memory space during parallel copy GC, these non-active application objects are substantially deleted from the memory 102.

[0024] Referring back to FIG. 3, memory 300 may include a memory stack 302, a heap space 304, a GC owner thread queue 306-1, and a GC sweep thread queue 306-2. The memory stack 302 may be a directory maintained by a runtime such as runtime 104 that has pointers to active application objects. In this example, application objects 106 are labeled in alphabetical order from "a" to "n". The arrows from stack 302 indicate pointers to application objects a and b. Application objects 106 may be represented using a tree structure. The tree structure may indicate the relationships between individual application objects. For example, application object a is related to application objects d, e, and f. The lines from application object a to application objects d, e, and f may indicate that application object a includes pointers to application objects d, e, and f. These relationships may indicate, for example, an execution call from one application object 106 to another, the use of data stored in one application object by computer instructions of another application object, and the like.

[0025] The heap space 304 can be an area of the memory 300 where the runtime 104 can maintain the application objects 106 of a computer application. The GC owner thread queue 306-1 and the GC sweeper thread queue 306-2 can be similar to the GC owner queue 112-1 of the GC owner thread 110-1 and the GC sweeper queue 112-2 of the GC sweeper thread 110-2 described with respect to FIG. 1. Referring again to FIG. 3, 306-start and 306-end can represent the start and end indexes of the GC owner queue and the GC sweeper queue, respectively. Additionally, the heap space 304 can include a from space 308 and a to space 310. The from space 308 can be the current memory space that the runtime 104 is using for the application object 106. The to space 310 can represent a new memory space where the garbage collection thread 110 is copying live application objects.

[0026] As shown, there are no pointers from the stack 302 or from any other application object to the application objects k and n. The absence of pointers can indicate that these application objects are non-active application objects. Thus, the garbage collection thread 110 can copy the application objects k and n to the to space 310 and can effectively delete these objects.

[0027] More specifically, in parallel copy GC, the runtime 104 can pause computer application threads during the GC time, i.e., when the garbage collection thread 110 is executing. Further, the garbage collection thread 110 can: 1) acquire space in the to-space 310; 2) copy application objects to the space acquired in the to-space 310; 3) set the forwarding pointer in the header of the original application object in the from-space 308 to point to the object copied in the to-space 310; 4) set the pointer in the copied object A' to point to another copied object B', which is the object that the original object was referenced by A, and remove the pointer in the copied object A' that was directed to the original B; and 5) find references to other application objects 106 by scanning the copied application objects, thereby copying the application objects. Since the application objects 106 can be referenced from several application objects 106, multiple garbage collection threads 110 can reach the same application object during the copy procedure. Thus, the garbage collection thread 110 copies the application objects atomically. Since only one garbage collection thread 110 can successfully copy the application object 106, the forwarding pointer is set atomically using a compare-and-swap operation. A thread that fails the compare-and-swap operation can thus delete its copy of the application object 106.

[0028] FIG. 4 is a block diagram of an exemplary process flow diagram of a method 400 for load-balanced work stealing reduction, according to some embodiments of the present disclosure. A garbage collection manager, such as the garbage collection manager 108, can execute the method 400.

[0029] In operation 402, the garbage collection manager 108 can determine that a thief thread, such as GC thief thread 110-2, has attempted work stealing. The garbage collection manager 108 can determine that an attempt has occurred based on whether a local index to the head of the GC thief queue 112-2 matches the global index. If they do not match, then GC thief thread 110-2 has attempted work stealing.

[0030] In operation 404, the garbage collection manager 108 can determine that the number of tasks in the owner queue meets or exceeds a predetermined threshold. If the number of tasks in the GC owner queue 112-1 is relatively low, reducing work stealing may not be useful. Therefore, the predetermined threshold may indicate a minimum number of tasks such that reducing work stealing improves efficiency.

[0031] In operation 406, the garbage collection manager 108 can determine that the GC owner queue 112-1 has heavyweight tasks queued. A heavyweight task can be a task for a heavyweight application object, such as a reference array. In some embodiments of the present disclosure, if an application object includes more than a predetermined number of tasks, the application object can represent a heavyweight task.

[0032] In operation 408, the garbage collection manager 108 can push a heavyweight task to the head of the GC owner queue 112-1. The garbage collection manager 108 can push the heavyweight task to the head of the GC owner queue 112-1 by: 1) locally decrementing the index to the head pointer, 2) storing an entry for the heavyweight task at the decremented head, and 3) globally updating the head pointer using a compare-and-swap (CAS) instruction. The CAS instruction can determine whether the heavyweight task has already been copied to the tospace. If not, the garbage collection manager 108 can update the head pointer.

[0033] FIG. 5 is a block diagram of an exemplary garbage collection manager 500 according to some embodiments of the present disclosure. In various embodiments, the garbage collection manager 500 is similar to the garbage collection manager 108 and can perform the methods described in FIG. 4 and / or the functions discussed in FIGS. 1-3. In some embodiments, the garbage collection manager 500 provides instructions for the aforementioned methods and / or functions to a client machine, whereby the client machine executes a method, or a portion of a method, based on the instructions provided by the garbage collection manager 500. In some embodiments, the garbage collection manager 500 can include software executed on hardware incorporated into a plurality of devices.

[0034] The garbage collection manager 500 includes a memory 525, a storage 530, an interconnect (e.g., BUS) 520, one or more CPUs 505 (also referred to herein as processors 505), an I / O device interface 510, an I / O device 512, and a network interface 515.

[0035] Each CPU 505 obtains and executes programming instructions stored in memory 525 or storage 530. The interconnect 520 is used to move data such as programming instructions between the CPU 505, I / O device interface 510, storage 530, network interface 515, and memory 525. The interconnect 520 can be implemented using one or more buses. The CPU 505 can be, in various embodiments, a single CPU, multiple CPUs, or a single CPU having multiple processing cores. In some embodiments, the CPU 505 can be a digital signal processor (DSP). In some embodiments, the CPU 505 includes one or more 3D integrated circuits (3DICs) (e.g., 3D wafer-level package (3DWLP), 3D interposer-based integration, 3D stacked IC (3D-SIC), monolithic 3D IC, 3D heterogeneous integration, 3D system-in-package (3DSiP), and / or package-on-package (PoP) CPU configurations). Memory 525 generally includes what is representative of random access memory (e.g., static random access memory (SRAM), dynamic random access memory (DRAM), or flash). Storage 530 generally includes what is representative of non-volatile memory such as a hard disk drive, solid state device (SSD), removable memory card, optical storage, and / or flash memory device. Additionally, storage 530 can include a storage area network (SAN) device, cloud, or other device connected to the garbage collection manager 500 via the I / O device interface 510 or to the network 550 via the network interface 515.

[0036] In some embodiments, the memory 525 stores the instructions 560. However, in various embodiments, the instructions 560 may be stored partially in the memory 525 and partially in the storage 530, or entirely in the memory 525, or entirely in the storage 530, or accessed on the network 550 via the network interface 515.

[0037] The instructions 560 can be processor-executable instructions for performing any part, or all, of the methods described in FIG. 3 and / or the functions discussed in FIGS. 1, 2A, and 2B.

[0038] In various embodiments, the I / O device 512 includes an interface capable of presenting information and receiving input. For example, the I / O device 512 can present information to a listener that interacts with the garbage collection manager 500 and receive input from the listener.

[0039] The garbage collection manager 500 is connected to the network 550 via the network interface 515. The network 550 can comprise a physical network, a wireless network, a cellular network, or different networks.

[0040] In some embodiments, the garbage collection manager 500 can be a multi-user mainframe computer system, a single-user system, or a server computer, or a similar device that receives requests from other computer systems (clients) with little or no direct user interface. Further, in some embodiments, the garbage collection manager 500 can be implemented as a desktop computer, a portable computer, a laptop or notebook computer, a tablet computer, a pocket computer, a telephone, a smartphone, a network switch or router, or any other suitable type of electronic device.

[0041] Note that FIG. 5 is intended to show representative major components of an exemplary garbage collection manager 500. However, in some embodiments, individual components may have a higher or lower complexity than that represented in FIG. 5, there may be components other than or in addition to those shown in FIG. 5, and the number, type, and configuration of such components may vary.

[0042] The present invention can be a system, method, and / or computer program product integrated at any conceivable level of technical detail. The computer program product can include a computer-readable storage medium (or multiple computer-readable storage media) having computer-readable program instructions for causing a processor to execute aspects of the present invention.

[0043] A computer-readable storage medium can be a tangible device that holds and stores instructions for use by an instruction execution device. The computer-readable storage medium can be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing, but is not limited thereto. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disks (DVDs), memory sticks, floppy disks, punch cards, or mechanically encoded devices such as raised structures within grooves in which instructions are recorded, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed to be a signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse passing through an optical fiber cable), or an electrical signal transmitted through a wire, which are all transient signals.

[0044] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to respective computing / processing devices, or may be downloaded from an external computer or an external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium within each computing / processing device.

[0045] The computer-readable program instructions for carrying out the operations of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, and may also be source code or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk® or C++, and procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on a user's computer as a stand-alone software package, may be executed partially on a user's computer, may execute partially on a user's computer and partially on a remote computer, or may be executed entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit in order to carry out aspects of the present invention.

[0046] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0047] These computer-readable program instructions may be provided to a computer, or other programmable data processing apparatus's processor to produce a machine, whereby the instructions executed via the computer or other programmable data processing apparatus's processor create means for implementing the functions / operations specified in one or more blocks of the flowchart and / or block diagram. Also, these computer-readable program instructions may be stored in a computer-readable storage medium capable of instructing a computer, programmable data processing apparatus, and / or other devices to function in a specific manner, whereby the computer-readable storage medium storing the instructions includes a product including instructions for implementing the manner of the functions / operations specified in one or more blocks of the flowchart and / or block diagram.

[0048] Moreover, the computer-readable program instructions may be loaded onto a computer, other programmable data processing apparatus, or other device to create a computer-implemented process by executing a series of operational steps on the computer, other programmable apparatus, or other device, whereby the instructions executed on the computer, other programmable apparatus, or other device implement the functions / operations specified in one or more blocks of the flowchart and / or block diagram.

[0049] Flowcharts and block diagrams in the drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions that include one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions noted in the blocks may be performed in an order different from that noted in the drawings. For example, two blocks shown in succession may in fact be accomplished as one step, may be executed simultaneously, substantially simultaneously, partially or wholly in a time-overlapped manner, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, can be implemented by a special-purpose hardware-based system that performs the specified functions or operations, or that executes a combination of special-purpose hardware and computer instructions.

Claims

1. determining that a thief thread has attempted to steal work from a garbage collection (GC) owner queue; determining that a number of tasks in the GC owner queue meets a predetermined threshold; determining that the GC owner queue has heavyweight tasks; moving the heavyweight task to the head position of the GC owner queue. A computer-implemented method comprising:

2. The step of moving the heavyweight task comprises: decrementing a local pointer to the head position of the GC owner queue; and storing the heavyweight task at the decremented local pointer to the beginning location. The computer-implemented method of claim 1 , comprising:

3. The step of moving the heavyweight task comprises: performing a compare and swap on the decremented local pointer and global pointer to the head position of the GC owner queue; determining that the heavyweight task is not copied to the to-space of the heap space; and updating the global pointer to the decremented local pointer. The computer-implemented method of claim 2 , further comprising:

4. The computer-implemented method of claim 1 , wherein the heavyweight tasks include a garbage collection task for application objects that contain reference arrays.

5. The computer-implemented method of claim 1 , wherein the heavyweight task has a number of references to other application objects that exceeds a predefined task reference threshold.

6. The computer-implemented method of claim 1 , wherein the GC owner queue comprises a double-ended queue.

7. 7. The computer-implemented method of claim 6, wherein the GC owner queue comprises a last-in, first-out queue.

8. A method for implementing a method for a computer-implemented program comprising: A procedure for determining when a thief thread has attempted to steal work from a garbage collection (GC) owner queue; determining that the number of tasks in the GC owner queue meets a predetermined threshold; determining that the GC owner queue contains a heavyweight task; and A procedure for moving the heavyweight task to the head position of the GC owner queue. having instructions configured to cause the device to carry out a method including Computer program.

9. The steps to move the heavyweight task are: decrementing a local pointer to the head position of the GC owner queue; and storing the heavyweight task at the decremented local pointer to the beginning location.

9. The computer program of claim 8, comprising:

10. The steps to move the heavyweight task are: performing a compare and swap on the decremented local and global pointers to the head position of the GC owner queue; determining that the compare and swap was successful; and updating said global pointer to said decremented local pointer; 10. The computer program of claim 9, further comprising:

11. 11. The computer program product of claim 8, wherein the heavyweight tasks comprise a garbage collection task for application objects having reference arrays.

12. 12. The computer program product of claim 8, wherein the heavyweight task has a number of references to other application objects that exceeds a predefined task reference threshold.

13. 13. The computer program product of claim 8, wherein the GC owner queue comprises a double-ended queue.

14. 14. The computer program product of claim 13, wherein the GC owner queue comprises a last-in, first-out queue.

15. one or more computer processing circuits; and When executed by the one or more computer processing circuits, the one or more computer processing circuits determining that a thief thread has attempted to steal work from a garbage collection (GC) owner queue; determining that a number of tasks in the GC owner queue meets a predetermined threshold; determining that the GC owner queue contains a heavyweight task; and moving the heavyweight task to the head position of the GC owner queue. One or more computer readable storage media storing program instructions configured to cause a method having A system comprising:

16. The steps to move the heavyweight task are: decrementing a local pointer to the head position of the GC owner queue; and storing the heavyweight task at the decremented local pointer to the beginning location. The system of claim 15, comprising:

17. The steps to move the heavyweight task are: performing a compare and swap on the decremented local and global pointers to the head position of the GC owner queue; determining that the compare and swap was successful; and updating said global pointer to said decremented local pointer; The system of claim 16 further comprising:

18. 18. The system of claim 15, wherein the heavyweight tasks include a garbage collection task for application objects having reference arrays.

19. 19. The system of claim 15, wherein the heavyweight task has a number of references to other application objects that exceeds a predefined task reference threshold.

20. 20. The system of claim 15, wherein the GC owner queue comprises a double-ended queue and a last-in, first-out queue.

Images