By encoding an exception triggering value in storage referenced by an instruction in an otherwise unused slot (e.g., the delay slot of a delayed control transfer instruction or an unused instruction position in a VLIW-based architecture) coinciding with a safe point, an efficient coordination mechanism can be provided for multi-threaded code. Because the mechanism(s) impose negligible overhead when not employed and can be engaged in response to an event (e.g., a start garbage collection event), safe points can be defined at call, return and/or backward branch points throughout mutator code to reduce the latency between the event and suspension of all threads. Though particularly advantageous for thread suspension to perform garbage collection at safe points, the techniques described herein are more generally applicable to program suspension at coordination points coinciding with calls, returns, branches or calls, returns and branches therein.
|
8. An apparatus comprising:
at least one processor operable to concurrently execute plural threads of a mutator computation, the plural threads execute mutator code, wherein mutator code comprises code that changes a state of heap-allocated storage and does not implement a garbage collection strategy; and
a safepoint trap handler, executable by the at least one processor, operable to preempt a thread of the plural threads if the thread triggers an exception that invokes the safepoint trap handler to handle the exception;
wherein the exception is selectively triggerable by execution of an instruction included in the mutator code in a delay slot of a delayed control transfer instruction that coincides with a safe point in a respective one of the mutator threads, the safe point is selected from a set comprising a call, a return and a backward branch, and the selective triggering is based on an indication settable to select preemption upon execution of the instruction.
1. A method of cooperative preemption for a multiprocessor, comprising:
inserting instructions in delay slots of delayed control transfer instructions at call and backward branch safe points in mutator code, stored in at least one computer readable medium, the instructions operable to selectively trigger an exception based on an indication stored in the at least one computer readable medium, the indication operable to be one of a group comprising set by a garbage collector and set for the garbage collector, the selective triggering of the exception invoking a safepoint trap handler to handle the exception, wherein mutator code comprises code that changes a state of heap-allocated storage and does not implement a garbage collection strategy;
executing the instructions utilizing at least one thread of at least one multiprocessor; and
suspending the at least one thread utilizing the safepoint trap handler, the safepoint trap handler executed by the at least one multiprocessor, when the safepoint trap handler is invoked to handle the exception by the selective triggering of the exception based on the indication.
12. A method of coordinating suspension of plural threads of a mutator, wherein the mutator comprises computation that changes a state of heap-allocated storage and does not implement a garbage collection strategy, the method comprising:
executing instructions, utilizing at least one thread of a processor, the instructions in delay slots of delayed control transfer instructions at call and backward branch safe points in mutator code, the mutator code stored in a computer readable medium, wherein mutator code comprises code that changes a state of heap-allocated storage and does not implement a garbage collection strategy;
triggering an exception on selected executions of the instructions at the call and backward branch safe points based on an indication settable operable to be one of the group comprising set by a garbage collector and set for the garbage collector, the triggering of the exception invoking a safepoint trap handler to handle the exception; and
suspending the at least one thread utilizing the safepoint trap handler, the safepoint trap handler executed by the processor, when the safepoint trap handler is invoked to handle the exception by the selective triggering based on the indication.
15. A computer program product encoded in at least one computer readable medium, the computer program product comprising:
a first set of instructions, encoded in at least one computer readable medium, operable to implement, when executed by a processor, a compiler that produces native instruction sequences directly executable on the processor, the instruction sequences corresponding to mutator code encoded in accordance with a virtual machine instruction set, the native instruction sequences include particular native instructions in delay slots of delayed control transfer instructions corresponding to calls and backward branches in the mutator code, wherein mutator code comprises code that changes a state of heap-allocated storage and does not implement a garbage collection strategy; and
a second set of instructions, encoded in the at least one computer readable medium, operable to implement, when executed by the processor, a safepoint trap handler, the safepoint trap handler operable to be invoked by the triggering of an exception that is selectively triggerable by execution of the particular native instructions by a thread of the processor based on an indication operable to be one of the group comprising set by a garbage collector and set for the garbage collector, the safepoint trap handler operable to suspend the thread when invoked by the selective triggering of the exception based on the indication.
2. The method of
3. The method of
executing the garbage collector utilizing the at least one multiprocessor.
4. The method of
5. The method of
6. The method of
executing the just-in-time (JIT) compiler utilizing the at least one multiprocessor.
7. The method of
inserting the instructions at return safe points in the mutator code.
9. The apparatus of
a just-in-time (JIT) compiler, executable on the at least one processor, that supplies the executable instruction that coincides with the safe point.
10. The apparatus of
11. The apparatus of
a garbage collector executable on the at least one processor and operable to set the settable indication.
14. The method of
16. The computer program product of
a third set of instructions, encoded in the at least one computer readable medium, operable to implement, when executed by the processor, the garbage collector.
|
This application is a continuation of U.S. application Ser. No. 09/986,231, filed Oct. 22, 2001, which is in turn a continuation-in-part of U.S. application Ser. No. 09/255,226, filed Feb. 22, 1999, now U.S. Pat. No. 6,308,319.
1. Field of the Invention
The present invention relates to synchronization amongst execution sequences in computer programs and, in some applications thereof, to techniques for facilitating garbage collection in multi-threaded software environments.
2. Description of the Related Art
Traditionally, most programming languages have placed responsibility for dynamic allocation and deallocation of memory on the programmer. For example, in the C programming language, memory is allocated from the heap by the malloc procedure (or its variants). Given a pointer variable, p, execution of machine instructions corresponding to the statement p=malloc (sizeof (SomeStruct)) causes pointer variable p to point to newly allocated storage for a memory object of size necessary for representing a SomeStruct data structure. After use, the memory object identified by pointer variable p can be deallocated, or freed, by calling free (p). Pascal and C++ languages provide analogous facilities for explicit allocation and deallocation of memory.
Unfortunately, dynamically allocated storage becomes unreachable when no chain of references (or pointers) can be traced from a “root set” of references (or pointers) to the storage. Memory objects that are no longer reachable, but have not been freed, are called garbage. Similarly, storage associated with a memory object can be deallocated while still referenced. In this case, a dangling reference has been created. In general, dynamic memory can be hard to manage correctly. In most programming languages, heap allocation is required for data structures that survive the procedure that created them. If these data structures are passed to further procedures or functions, it may be difficult or impossible for the programmer or compiler to determine the point at which it is safe to deallocate them.
Because of this difficulty, garbage collection, i.e., automatic reclamation of heap-allocated storage after its last use by a program, can be an attractive alternative model of dynamic memory management. Garbage collection is particularly attractive for languages such as the Java™ language (Java™ and all Java™—based marks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries), Prolog, Lisp, Smalltalk, Scheme, Eiffel, Dylan, M L, Haskell, Miranda, etc. See generally, Jones & Lins, Garbage Collection: Algorithms for Automatic Dynamic Memory Management, pp. 1-41, Wiley (1996) for a discussion of garbage collection and of various classical algorithms for performing garbage collection.
In general, garbage collection methods can be described with reference to a garbage collection strategy implemented by a “collector” and its interaction or coordination with a useful computation—a “mutator”—that changes the state of heap-allocated storage. Many collector implementations, including some mark-sweep and copying collector implementations, are based on a stop-start approach, i.e., they involve suspending the mutator, collecting garbage, and resuming execution of the mutator after garbage collection. In such implementations, garbage collection is performed when the “root set” of pointers to dynamically allocated memory locations referenceable by the mutator is available to the garbage collector. A mutator in this state is called “consistent,” and one that is not is “inconsistent.”
Typically, a compiler for a garbage-collected language supports the collector by generating code that allocates objects, by describing storage locations that make up the root set, and by describing the layout of objects allocated from the heap. For efficiency, compilers typically generate code that uses registers and/or stack locations provided by a target processor architecture. As a result, execution of compiled code puts pointers in such registers or stack locations. Unfortunately, a mutator running such code is generally inconsistent, because the exact set of registers and/or stack locations containing pointers can change with every instruction. The overhead of exactly maintaining a root set description at each instruction tends to defeat the purpose of using registers and stack locations in the first place. Compilers therefore identify safe points in the code, places in the code where the compiler emits information describing which registers and stack locations contain pointers. When a mutator is suspended at a safe point it is consistent and hence garbage collection can proceed. See generally, Appel, Modern Compiler Implementation in C: Basic Techniques, pp. 291-297, Cambridge University Press (1998) for a description of compiler support for garbage collection.
Accordingly, a mechanism is desired by which a processor executing mutator code may suspend execution at a safe point defined therein to facilitate garbage collection. A desirable mechanism is computationally efficient and imposes minimal overhead on the mutator computation. Furthermore, it is desirable for the mechanism to operate in the context of multi-threaded mutator computation and to limit the delay between a request to start garbage collection and suspension of all threads of the mutator computation.
Encoding an exception triggering value in storage referenced by an instruction in an otherwise unused slot (e.g., the delay slot of a delayed control transfer instruction or an unused instruction position in a VLIW-based architecture) coinciding with a safe point provides an efficient coordination mechanism for multi-threaded code. Because the mechanism(s) impose negligible overhead when not employed and can be engaged in response to an event (e.g., a start garbage collection event), safe points can be defined at call, return and/or backward branch points throughout mutator code to reduce the latency between the event and suspension of all threads. In contrast, mechanisms based on conditional execution of suspension code can impose substantial overhead. Furthermore, unlike mechanisms based on self-modifying code, complexities associated with maintaining memory model consistency are avoided. Though particularly advantageous for thread suspension to perform garbage collection at safe points, the techniques described herein are more generally applicable to program suspension at coordination points coinciding with calls, returns, branches or combinations thereof.
Illustrative embodiments in accordance with the present invention exploit a variety of exception triggering instructions and configurations of storage referenced thereby to suspend threads at safe points coinciding with call, return and/or backward branch sites. Some embodiments in accordance with the present invention include support for garbage collection. Some embodiments in accordance with the present invention include compiler techniques and implementations to generate suitable execution sequences of instructions.
The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.
The use of the same reference symbols in different drawings indicates similar or identical items.
To facilitate garbage collection, it is desirable to provide a mechanism by which threads of a mutator can be efficiently suspended at safe points. Conditional execution of suspension code at such safe points is one technique. For example, at selected safe points in mutator code, a compiler can insert instructions that check a flag that is set when garbage collection is desired and cleared when the garbage collection has completed. If the flag is set, the suspension code is run to suspend the mutator. This technique can be described as “polling at safe points.” Unfortunately, the polling technique introduces substantial overhead. A flag test must be performed at every safe point and millions of safe points will typically be traversed between garbage collection cycles. Extra flag test and branch instructions degrade performance, increase code size and consume processor resources such as instruction cache space and flags.
Another technique involves self-modifying code. When garbage collection becomes necessary or is desired, all threads are suspended, and every currently executing method (i.e., the code associated with each suspended thread) is patched so that when execution is resumed each method will suspend itself at the next safe point. After all threads are suspended, the patches are removed. This technique can be described as “patching the safe points.” Unfortunately, dynamic code modifications are complex and often error prone, especially on a multiprocessor. In particular, memory maps or similar data structures should be provided to encode locations where code patches are to be made and instruction caches should be flushed upon patching to ensure memory consistency. In addition, processor pipelines may stall when handling store operations that affect the instruction stream. For these reasons, applying and removing patches can impose significant overhead. Since multi-threaded computations may be particularly amenable to multiprocessor implementations, avoiding the complexity and overhead of properly handling self-modifying code is desirable.
Dynamically Allocated Memory and Safe Points
Memory object 135 represents dynamically allocated storage that is no longer reachable and will be collected and returned to a free space pool of heap 102 by garbage collection. Referencing graphs for pointers represented in other stack frames in the calling hierarchy (e.g., stack frame 113) or represented in other register contexts are omitted for clarity and only the partial referencing graph associated with the current function is shown. However, based on the description herein, persons of ordinary skill in the art will appreciate that at any given point in the execution and calling sequence of the mutator thread, a complete set of reachable objects in heap 102 and a root set of pointers thereto can be defined by combining the contributions for each function in the calling hierarchy.
As described above, a root set of pointers at least partially represented in registers or stack locations necessitates some method of tracking of those registers or stack locations containing valid pointers. Tracking can be continuous with significant overhead or, more preferably, can be limited to predefined safe points in the mutator code. If predefined safe points are utilized, attractive safe points must be identified and a mechanism for suspending a mutator thread (or threads) at such safe points is needed. When a thread is suspended, all the stack frames except the most recently entered (i.e., all the calling functions in the calling hierarchy) must be at call sites, hence every call site must be a safe point. Therefore, mutator code should include information describing the registers and stack locations, if any, containing pointers at call sites.
In addition, other safe points may be defined to reduce the period during which a thread executes with garbage collection pending. For example, returns from functions or methods are another likely safe point site. To ensure that a thread will not run long with garbage collection pending, backward branches can also be designated as safe points. In general, backward branches define loops, and safe points at backward branches allow loops to be interrupted for garbage collection. A compiler may elect to place safe points elsewhere in the code it generates, for example in a method's prolog to prevent recursive code from holding up garbage collection indefinitely. In some embodiments in accordance with the present invention, safe points are defined at call sites, return sites and backward branches using an exception triggering instruction. For example, in one exemplary embodiment now more completely described, the exception triggering instruction may be encoded in a delay slot of a delayed branch instruction providing the call, return, or backward branch.
Delay Slot Encoded Instructions Referencing a Global Store
In an exemplary embodiment in accordance with the present invention, safe points are defined at selected sites coinciding with delayed control transfer instructions in potentially inconsistent threads of a mutator computation. Exception triggering instructions are encoded in delay slots of the delayed control transfer instructions. In embodiments suitable for certain processor architectures (including for processors conforming to the SPARC® V9 architecture), calls, returns, and backward branches are all implementable using delayed control transfer instructions. As a result, safe points can be defined in mutator code to coincide with each type of delayed control transfer instruction and thread suspension can be provided for each such safe point using suspension exception and trap handling mechanisms described herein.
SPARC architecture based processors are available from Sun Microsystems, Inc, Palo Alto, Calif. SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the United States and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems.
In other embodiments, including those suitable for other processor architectures, different sets of safe points may be defined. For example, and without limitation, call-site only or call-site and backward branch safe point only strategies may be employed. In addition to the safe point location described above, safe points may be defined within method prologs and/or within memory allocators. Additionally, safe point sets may be implemented where some of the safe points are supported using delay slot encoding of exception triggering instructions and others are supported using other thread suspension mechanisms. For example, one suitable complementary thread suspension mechanism is described in greater detail in U.S. patent application Ser. No. 09/229,272, entitled “THREAD SUSPENSION SYSTEM AND METHOD,” the entirety of which is incorporated herein by reference. Based on the description herein, persons of ordinary skill in the art will appreciate implementations suitable for a wide variety of processor instruction sets supporting delayed branch encodings and for a wide variety of safe point definitions.
Focusing illustratively on an exemplary embodiment in accordance with the present invention, safe points are defined at call sites, return sites and backward branches and exception triggering instructions are encoded in delay slots of delayed branch instructions providing a call, return, or backward branch for potentially inconsistent threads of a mutator computation.
Normally, i.e., when garbage collection is not pending, global register G1 contains a value that, when referenced by an exception triggering instruction (e.g., 212 or 222), does not trigger an exception or invoke a thread suspension trap handler. On the other hand, when garbage collection is desired or becomes necessary, a trapping value is set in global register G1. Thereafter, when thread 210 encounters an exception triggering instruction referencing the trapping value in global register G1, an exception is triggered and thread suspension trap handler 240 is invoked. After all potentially inconsistent threads are suspended, the value in global register G1 may be reset to a non-triggering value.
Although thread suspension mechanisms described herein are applicable to a wide variety of processor architectures, instruction sets and execution environments, they can be better understood in the context of a specific exemplary configuration. It is noted that the Java™ virtual machine is one example of a garbage collected execution environment and the SPARC architecture is merely one exemplary processor architecture. The framework established by each is useful for illustrating an application of the inventive concepts described herein; however, the invention is in no way limited to Java™ environments, virtual machine environments, or SPARC processors. Indeed, as will be appreciated based on the claims that follow, application of the inventive concepts described herein is not limited to garbage collection. Therefore, without limitation to the specific instructions, data stores, trapping values or exception handling configuration thereof, an exemplary configuration for a SPARC-V9 architecture microprocessor running a Java™ virtual machine environment is now described.
In the SPARC architecture, a control transfer instruction functions by changing the value of the next program counter (nPC) or by changing the value of both the program counter (PC) and the next program counter (nPC). When only nPC is changed, the effect of the transfer of control is delayed by one instruction cycle. Most control transfers in SPARC-V9 (including conditional and unconditional branches, calls, jumps and returns) are of the delayed variety. The instruction following a delayed control transfer instruction is said to be in the delay slot of the control transfer instruction and is executed (unless the control transfer instruction annuls it) before control is transferred to the target instruction. In general, delayed control transfers have been used for avoiding stalls in the execution pipeline(s) of a processor by allowing a compiler to move an instruction having execution sequence position before the control transfer into the delay slot, thereby avoiding a stall associated with fetch, decode, etc. of the control transfer target.
In various embodiments in accordance with the present invention, delay slots are also used to support thread suspension by placing an exception triggering instruction in delay slots of delayed control transfer instructions coinciding with safe points. For example, on a SPARC processor, trapping versions of tagged arithmetic instructions (e.g., TADDccTV or TSUBccTV) can be used to trigger a thread suspension trap. The tagged add and subtract instructions operate on tagged-format data, in which the tag is the two low-order bits of each operand. If either of the operands has a nonzero tag, a tag mismatch is detected and a tag_overflow exception is triggered. Building on these facilities, a compiler can place a tagged arithmetic instruction (e.g., TADDccTV) in the delay slot of each control transfer instruction that coincides with a safe point. The tagged arithmetic instruction operates on the contents of a global register, e.g., global register G1. In the SPARC architecture, two sets of global registers are defined, one of which is selected by the state of the PSTATE.AG register field. Therefore, the compiler should either ensure that all potentially inconsistent mutator threads address the same global register set, or alternatively, that the global register sets associated with all potentially inconsistent mutator threads encode consistent global register values (e.g., a consistent trapping or non-trapping value in the global register G1 instances of both register sets).
A garbage collected execution environment, such as that implemented by a Java™ virtual machine, can be configured to set a global register accessible to each mutator thread and referenced by the tagged arithmetic instructions (e.g., global register G1) with a trapping value (e.g., xxx . . . x01 for the TADDccTV instruction) when collection is required or desired and to configure the Trap Table entry (tt=02316) corresponding to the tag_overflow exception to invoke a thread suspension trap handler.
In an exemplary Java™ virtual machine implemented on a SPARC processor, the Java™ virtual machine clears, typically on startup or process creation, global register G1 which is referenced by tagged arithmetic instructions placed by a Java™ compiler into delay slots of control transfer instructions coinciding with safe points in mutator code. In addition and typically on startup or process creation, the Java™ virtual machine associates thread suspension trap handler 240 with the tag_overflow exception. When garbage collection is desired or necessary, the Java™ virtual machine sets a tag bit in global register G1. Thereafter, when mutator threads (e.g., threads 210 and 220) encounter safe points (e.g., at backward branches, calls, returns, etc.) execution of the delay slot tagged arithmetic instructions triggers a tag_overflow exception and invokes thread suspension trap handler 240. Thread suspension trap handler 240, in turn, suspends the trapping mutator thread. Once all mutator threads are suspended, the Java™ virtual machine can clear the tag bit (or bits) set in global register G1 and can perform garbage collection in accordance with any suitable automatic storage management system implemented thereby.
Detection of an all-threads-suspended condition may be performed by thread suspension trap handler 240 or alternatively may be a function of a particular collector implementation. In addition, one or more threads of a multi-threaded mutator may be guaranteed consistent whenever active, during certain phases of activity, or while executing certain functions. In such circumstances, the guaranteed consistent threads may be suspended without regard to a next safe point. In essence, all points are safe points in a guaranteed consistent thread. As a result, suspension of guaranteed consistent threads may be performed outside of the context of mechanisms described herein, while mechanisms described herein may be employed for those threads that are potentially inconsistent. In such circumstances, suspension of at least potentially inconsistent threads should be detected. Suspension of guaranteed consistent threads may be performed at any time after collection is required or desired; however, in certain configurations it may be profitably delayed until all potentially inconsistent threads are suspended. In either case, suspension of guaranteed consistent threads may be performed by mechanisms described herein or otherwise (e.g., by a particular collector implementation).
In the SPARC processor architecture, association of thread suspension trap handler 240 with a particular exception involves a trap table entry, although other processor architectures may employ differing exception handling configurations and suitable modification will be apparent to persons of ordinary skill in the art based on the description herein. In the SPARC processor architecture, a trap table is defined and is indexed using a trap type indication to vector to the associated handler code. The first eight instructions of a trap handler can be encoded in the trap table entry itself. Therefore in some embodiments, instructions of thread suspension trap handler 240 are encoded in a trap table entry and vectoring thereto is via the trap type index. For thread suspension trap handlers numbering more than 8 instructions, an additional vector to handler code is encoded in the trap table entry.
Many implementations of a thread suspension trap handler are suitable. However, generally speaking, thread suspension trap handler code should obtain the location of the trap (TPC[TL] on a SPARC processor) and save it. The saved trap location can then be used by a garbage collector to select the proper map of registers and/or stack locations containing pointers.
Although the tagged arithmetic instructions are attractive as exception triggering instructions because they can typically be employed by the compiler solely for thread suspension and therefore without regard for conflicting usage of the tag_overflow exception, other exception triggering functions can also be employed in delay slots with suitably-configured exception handler facilities. In general, suitable exception triggering instructions will be of a type that generates precise (rather than imprecise) traps. Preferably, the selected exception triggering instruction is not employed for purposes other than thread suspension in the mutator code. However, if the selected exception triggering instruction is used for purposes in addition to thread suspension, corresponding modifications may be made to trap handler code. In such cases, handler code will need to distinguish between thread suspension-related usage of the corresponding exception and other usage thereof, e.g., by checking a safe point list to determine whether a trapping location is a safe point and, if so, branching to thread suspension trap handling. Depending on the specific configuration, discriminator code in a first-level trap handler or single unified trap handler and/or opportunistic installation of an alternate handler may be suitable. Suitable modifications for particular processors, instruction sets and execution environments will be apparent to persons of ordinary skill in the art based on the description herein.
In one specific exemplary embodiment in accordance with
Delay Slot Encoded Trap Instructions
Another exemplary embodiment in accordance with the present invention employs a trap instruction as a delay slot instruction referencing storage encoded with a trapping value. As before, safe points are defined at selected sites coinciding with delayed control transfer instructions in potentially inconsistent threads of a mutator computation. However, trap instructions rather than tagged arithmetic instructions are encoded in delay slots of the delayed control transfer instructions and a corresponding exception is employed for triggering a thread suspension trap handler. By using the storage local to a mutator thread for an exception triggering value, trap instruction based embodiments can avoid dedication of a global register to thread suspension. In one embodiment in accordance with the present invention, condition codes are defined as part of a thread's state and a trap instruction triggers an exception based on condition code state.
As before, although thread suspension mechanisms described herein are applicable to a wide variety of processor architectures, instruction sets and execution environments, they can be better understood in the context of a specific exemplary configuration. Therefore, without limitation to the specific instructions, data stores, trapping values or exception handling configuration thereof, an exemplary trap instruction based configuration is described in the context of the SPARC-V9 feature set.
The SPARC architecture defines a Condition Codes Register (CCR) and a Trap on condition codes (Tcc) instruction. As presently defined, the condition codes register includes an integer condition codes field (icc) and an extended integer condition codes field (xcc). A selection field in valid Tcc instructions selects between the icc and the xcc fields for evaluation of a specified trap condition. See generally, Weaver and Germond, The SPARC Architecture Manual Version 9, Prentice-Hall, Inc. (1994), pp. 237-238. In one embodiment in accordance with the present invention, an extra 4-bit garbage collection condition code field (gcc) is defined in the condition codes register (bits 0-3 are currently used for the integer condition codes and bits 4-7 for the extended condition codes) and a selection value is defined for selection of gcc for evaluation of a trap condition specified in a Tcc instruction. In this way, a trap on garbage collection condition code facility is provided in the context of an augmented Tcc instruction. Unlike a global register, the state of a condition codes register is maintained on a per-thread basis, with per-thread values residing in machine registers when that thread is executing. Therefore, to set a trapping value in the “condition codes register” for each thread of a multi-threaded mutator, the condition code register state associated with each mutator thread should be set to a trapping value. A modified WRite Condition Codes Register (WRCCR) instruction (modified to also write the gcc field) can be used to set a trapping value in the condition code register state associated with a current mutator thread.
When a Tcc instruction is executed with condition codes register state encoding a trapping value, a trap_instruction exception is triggered and a handler associated with a corresponding trap table entry is invoked. In the context of a SPARC V9 style trap handling mechanism, multiple trap table entries are defined for trap_instruction exceptions, each corresponding to a specific trap operation (one of 16 for both icc- and xcc-denominated trap operations). Building on this mechanism, plural trap table entries for gcc-denominated trap operations can also be defined, although even a single gcc-denominated trap operation and associated trap table entry would be suitable. As before, a thread suspension trap handler (e.g., thread suspension trap handler 240) is associated with the trap table entry (or entries).
Building on these facilities, a compiler can place a trap on garbage collection condition codes instruction (e.g., a Tcc referencing the gcc field) in the delay slot of each control transfer instruction that coincides with a safe point. The trap on garbage collection condition codes instruction references (as storage for a trapping value) the gcc field of the condition codes register.
A garbage collected execution environment, such as a Java™ virtual machine, can be configured to set the gcc field for each mutator thread with a trapping value (e.g., xxx1 for a Tcc instruction trapping on the lowest order, or “c”, bit of the gcc field) when collection is required or desired and to configure (typically on startup or process creation) the Trap Table entry corresponding to the trap_instruction exception for the specified gcc condition to invoke a thread suspension trap handler. For each mutator thread, such a Java™ virtual machine clears the gcc field referenced by trap on garbage collection condition codes instructions placed by a Java™ compiler into delay slots of control transfer instructions coinciding with safe points in the mutator code. When garbage collection is desired or necessary, the Java™ virtual machine sets a trapping value in the gcc field for each potentially inconsistent mutator thread. Thereafter, when mutator threads (e.g., threads 210 and 220 of
Mutator Thread and Suspension Mechanism Interactions
Depending on the execution environment in which mutator process 301 executes, trapping value storage may include a register, stack location, field or memory location such as a global register G1 (see e.g.,
For simplicity, the description herein presumes that all potentially inconsistent mutator threads including 310 and 320 allocate from, and reference storage in, a unified heap. Therefore, garbage collection is performed after all potentially inconsistent threads that reference the heap are suspended. Nonetheless, configurations are possible in which a mutator process includes distinct subsets of threads referencing storage in distinct portions of a heap or in distinct heaps. In such configurations, all threads of the mutator process need not be suspended before a portion of the heap or a distinct heap is garbage collected. Proper selection of subsets of threads for suspension in such circumstances will be apparent to persons of ordinary skill in the art based on the description herein.
When collection is desired or necessary, storage is set with a trapping value (or trapping values). In exemplary embodiments in accordance with the present invention, each thread is suspended, a trapping value written into thread local storage 490 and the thread is resumed. Because instances of trapping value storage are associated with mutator threads and because in typical uniprocessor implementations, a single thread at a time is executed, suspension exception and trap handling mechanism 440 successively brings each thread into memory by suspending the thread. For other implementations, including e.g., those for multiprocessors executing multiple threads, thread suspension and subsequent resumption may be avoided. Execution of a trapping delay slot instruction 414 referencing the trapping value store causes an exception that is handled by a suspension trap handler (not separately shown) of suspension exception and trap handling mechanism 440, whereupon the trapping thread is suspended and the trapping value store associated with the trapping thread is reset to a non-trapping value. In some embodiments, resetting of the trapping value store is performed by the suspension trap handler, while in others, the resetting may be more closely tied to performance or completion of garbage collection or to eventual resumption of mutator threads after garbage collection.
When collection is desired or necessary, trapping value store 550 is set with a trapping value. Execution of a trapping delay slot instruction 514 referencing trapping value store 550 causes an exception that is handled by a suspension trap handler (not separately shown) of suspension exception and trap handling mechanism 540, whereupon the trapping thread is suspended. Once all potentially inconsistent threads referencing heap storage or a distinctly collected portion thereof are suspended, garbage collection is performed (551) and thereafter the suspended mutator threads are resumed (552). In some embodiments, resetting of trapping value store 550 is performed by the suspension trap handler, while in others, the resetting may be more closely tied to performance or completion of garbage collection or to eventual resumption of mutator threads after garbage collection.
Mutator Code Preparation
A variety of execution environments and mutator code instruction selections have been described herein.
In any case, compiler 610 (as an exemplary mutator code preparation facility) takes a source language encoding 620 of mutator process instructions (e.g., Java language statements, “C” or “C++” source code, etc.) and performs operations to generate executable mutator code 630 (e.g., SPARC machine code, other processor object code, Java virtual machine bytecodes, etc.). In some embodiments, source language encoding 620 includes instructions encoded in computer readable media or received incrementally or in toto via communication media such as a local area, wide area or telecommunications network.
In any case, compiler 610 (as an exemplary mutator code preparation facility) takes a source language encoding 620 of mutator process instructions (e.g., Java™ language statements, “C” or “C++” source code, etc.) and performs operations to generate executable mutator code 630 (e.g., SPARC machine code, other processor object code, Java™ virtual machine bytecodes, etc.). In some embodiments, source language encoding 620 includes instructions encoded in computer readable media or received incrementally or in toto via communication media such as a local area, wide area or telecommunications network.
Mutator code 630 includes machine instructions corresponding to source language encoding 620 as well as exception triggering instructions placed in delay slots or control transfer instructions by compiler 610 and data layout descriptions at safe points, all as described above with respect to various embodiments. As described above, compiler 610 emits information descriptive of those registers 680, heap 670 storage locations and/or, in some embodiments, stack locations (not shown) containing live pointers at safe points in mutator code 630, such that collector code 640 can ascertain the root set of pointers. In an exemplary JIT compiler implementation generating exact VM object code for a SPARC processor, the following source code:
/* ---------------------------------------------------------------
*/
class smap {
public static void main(String a[ ]) {
Object x=new Object( );
int y=3;
String z=a[0];
smap q=new smap( );
q.foo(x,y,z);
}
void foo(Object a, int b, String c) { }
smap( ) { }
}
generates the following JIT output:
/* ---------------------------------------------------------------
*/
/* *** JIT output ***
*/
/* *** format:
<bytecode-index> <bytecode> {bytecode-argument}
{SPARC instruction}
Stack map: sparcPC=<relative-pc-of-instruction-with-
map>
{SPARC instruction} *** */
DYNAMICALLY COMPILING smap.main == MethodEntry
save %sp, 0, %sp
st %g0, [%sp − 4096]
lduw [%fp + 64], %g2
st %g2, [%sp + 64]
0 new bb 0001
sethi %hi(0xb4000), %ol
Stack map: sparcPC=20
call 5
lduw [%sp + 64], %o0
or %o0, 0, %10
3 dup 59
4 invokespecial b7 0003
or %g0, %10, %o0
lduw [%o0 + 0], %g0
Stack map: sparcPC=40
call a
nop
7 astore_1 4c
or %g0, %10, %i0
8 iconst_3 06
9 istore_2 3d
or %g0, 3, %i2
10 aload_0 2a
11 iconst_0 03
12 aaload 32
lduw [%i1 + 8], %I1
subcc %g0, %I1, %g0
tcc %icc, %g0, 5
lduw [%i1 + 12], %I1
13 astore_3 4e
or %g0, %l1, %i3
14 new bb 00 02
sethi %hi(0x17d000), %o1
Stack map: sparcPC=80
call 14
lduw [%sp + 64], %o0
or %o0, 0, %I2
17 dup 59
18 invokespecial b7 00 04
or %g0, %I2, %o0
lduw [%o0 + 0], %g0
Stack map: sparcPC=100
call 19
nop
21 astore 3a 04
or %g0, %I2, %i4
23 aload 19 04
25 aload_1 2b
26 iload_2 1c
27 aload_3 2d
28 invokevirtual b6 0005
or %g0, %i4, %o0
lduw [%o0 + 0], %g2
or %i3, %g0, %o3
or %i2, %g0, %o2
or %i0, %g0, %o1
nop
sethi %hi(0x4003000), %g3
Stack map: sparcPC=140
call 23
nop
31 return b1
Method Exit
jmpl [%i7 + 8], %g0
restore %g0, %g0, %g0
nop
where all instructions that generate maps in the above example are call-type instructions. Exemplary stack maps correspond to sparcPC values as follows:
/* ---------------------------------------------------------------
*/
/* *** stack maps *** */
/* *** format:
sparcPC = <relative PC of instruction with map>
regs: {register with pointer}
vars: {variable with pointer}
ostk: {operand stack element with pointer}
rcvr = <receiver>
sig = <signature of callee> *** */
Stack maps for smap.main
sparcPC = 20,
regs: %i1
vars:
ostk:
rcvr = 0,
sig = (I)LR;
sparcPC = 40,
regs: %o0 %I0 %i1
vars:
ostk:
rcvr = 1,
sig = ( )V
sparcPC = 80,
regs: %i0 %i1 %i3
vars:
ostk:
rcvr = 0,
sig = (I)LR;
sparcPC = 100,
regs: %o0 %12 %i0 %i1 %i3
vars:
ostk:
rcvr = 1,
sig = ( )V
sparcPC = 140,
regs: %o0 %o1 %o3 %i0 %i1 %i3 %i4
vars:
ostk:
rcvr = 1,
sig = (Ljava/lang/Object;ILjava/lang/String;)V
sparcPC = 148,
regs:
vars:
ostk:
where, for example, the stack map corresponding to a sparcPC value of 100 indicates that output register 0 (% o0), local register 2 (% l2), and input registers 0, 1 and 3 (% i0% i1% i3) contain pointers and where the information encoded in the sparcPC indexed stack maps is particular to a SPARC processor embodiment of a Java™ virtual machine.
where, for example, the stack map corresponding to a SparcPC value of 100 indicates that output register 0 (% o0), local register 2 (% l2), and input registers 0, 1 and 3 (% i0% i1% i3) contain pointers and where the information encoded in the sparcPC indexed stack maps is particular to a SPARC processor embodiment of a Java virtual machine.
Embodiments described herein are applicable to a wide variety of processor architectures, instruction sets and execution environments. Therefore, the specific data layout descriptions suitable for a SPARC processor are merely exemplary. Persons of ordinary skill in the art will appreciate suitable modifications for other processor architectures, instruction sets and execution environments based on the description herein.
Garbage Collectors
Collector code 640 is exemplary of any of a number of collector implementations implementing any of a number of garbage collection methods. By way of example and not limitation, two suitable tracing collector methods are now summarized. In general, tracing methods involve traversal of reference chains through memory to identify live, i.e., referenceable, memory objects. One such tracing collector method is the mark-sweep method in which reference chains through memory are traversed to identify and mark live memory objects. Unmarked memory objects are garbage and are collected and returned to the free pool during a separate sweep phase. A mark-sweep garbage collector implementation typically includes an additional field, e.g., a mark bit, in each memory object. Mark-compact collectors add compaction to the traditional mark-sweep approach. Compaction relocates live objects to achieve beneficial reductions in fragmentation.
Another tracing method, copying collection, divides memory (or a portion thereof) into two semi-spaces, one containing current data and the other containing old data. Copying garbage collection begins by reversing the roles of the two semi-spaces. The copying collector then traverses the live objects in the old semi-space, FromSpace, copying reachable objects into the new semi-space, ToSpace. After all the live objects in FromSpace have been traversed and copied, a replica of the data structures exists in ToSpace. In essence, a copying collector scavenges live objects from amongst the garbage. A beneficial side effect of copying collection is that live objects are compacted into ToSpace, thereby reducing fragmentation.
Other Embodiments
While the invention has been described with reference to various embodiments, it will be understood that these embodiments are illustrative and that the scope of the invention is not limited to them. Many variations, modifications, additions, and improvements of the embodiments described are possible. For example, while much of the description herein has been in the context of multi-threaded mutators, use of the term thread does not require multiple-threads. Indeed, non-threaded or single-threaded processes may also fall within the scope of some claims. Similarly, while delay slots of delayed control transfer instructions provide one suitable implementation, more generally, other unused instruction positions may be exploited in other implementations. For example, in variations adapted for very long instruction word-type (VLIW) architectures or more generally for processor architectures that explicitly encode instruction level parallelism, unused horizontally-encoded instruction positions may be similarly employed. As a general matter, in such explicitly parallel exploitations, a trapping instruction can be encoded as an operation executable in parallel with one or more operations that coincide with a safe point. In general, the technique may be somewhat more flexible in processor architectures that explicitly encode instruction level parallelism since suitable unused instruction positions do not presuppose a delayed control transfer instruction or delay slot. Persons of ordinary skill in the art will appreciate suitable adaptation of techniques described herein for exploitation in such processor architectures. As before, a trapping instruction can be encoded in a position that coincides with a safe point and, based on a state settable under control of a coordination facility, such as for a garbage collector, the trapping instruction selectively vectors to a thread suspension facility such as a trap handler.
In an illustrative variation suitable for processor architectures such as the MAJC™ microprocessor architecture, a conditional trap instruction may be employed. For example, in the MAJC architecture, a trapc instruction is defined that will trap to a trap handler based on whether or not a bit is set in a processor status register (PSR). Accordingly, in an exemplary MAJC architecture exploitation, a trapc instruction is used in place of a tagged arithmetic instruction and a PSR bit (e.g., PSR.tce) may be employed in place of a global register. As before, a mutator includes an instance of a trapping instruction (namely an instance of the trapc instruction) in a position coinciding with a safe point (e.g., in an otherwise unused VLIW position or slot). An execution environment that attempts to coordinate operation of multiple threads (e.g., for garbage collection) encodes an exception triggering value in an appropriate location. MAJC is a trademark of Sun Microsystems, Inc. in the United States and other countries.
Based on the techniques described herein, persons of ordinary skill in the art will appreciate exploitations suitable for a wide variety of processor architectures including pipelined, VLIW, single instruction multiple data (SIMD), multiple instruction multiple data (MIMD), and explicitly parallel instruction processor architectures. More generally, structures and functionality presented as hardware in the exemplary embodiment may be implemented as software, firmware, or microcode in alternative embodiments. These and other variations, modifications, additions, and improvements may fall within the scope of the invention as defined in the claims that follow.
Bush, William, Tremblay, Marc, Wolczko, Mario I.
Patent | Priority | Assignee | Title |
10282227, | Nov 18 2014 | Intel Corporation | Efficient preemption for graphics processors |
10459656, | Jun 25 2018 | International Business Machines Corporation | Method and apparatus to represent activation frame for pause-less garbage collection |
10496534, | Mar 27 2017 | Microsoft Technology Licensing, LLC | Manual memory management using lazy patching |
10831400, | Jun 25 2018 | International Business Machines Corporation | Method and apparatus to represent activation frame for pause-less garbage collection |
11204767, | Jan 06 2020 | International Business Machines Corporation | Context switching locations for compiler-assisted context switching |
11556374, | Feb 15 2019 | International Business Machines Corporation | Compiler-optimized context switching with compiler-inserted data table for in-use register identification at a preferred preemption point |
7926035, | Apr 24 2007 | Microsoft Technology Licensing, LLC | Testing multi-thread software using prioritized context switch limits |
8200718, | Jul 02 2009 | Parallelized, incremental garbage collector | |
8826253, | Dec 15 2008 | Apple Inc. | Delayed insertion of safepoint-related code |
Patent | Priority | Assignee | Title |
5088036, | Jan 17 1989 | HEWLETT-PACKARD DEVELOPMENT COMPANY, L P | Real time, concurrent garbage collection system and method |
5321834, | Nov 28 1989 | Xerox Corporation | Method and system for reclaiming unreferenced computer memory space |
5557771, | Dec 01 1990 | Hitachi, Ltd. | Data processing system and storage device and auxiliary memory bits for controlling data protection in the storage device |
5560003, | Dec 21 1992 | AONIX, S A | System and hardware module for incremental real time garbage collection and memory management |
5560028, | Nov 05 1993 | INTERGRAPH HARDWARD TECHNOLOGIES COMPANY | Software scheduled superscalar computer architecture |
5842016, | May 29 1997 | Microsoft Technology Licensing, LLC | Thread synchronization in a garbage-collected system using execution barriers |
5920876, | Apr 23 1997 | Oracle America, Inc | Performing exact garbage collection using bitmaps that identify pointer values within objects |
5930508, | Dec 16 1996 | SAMSUNG ELECTRONICS CO , LTD | Method for storing and decoding instructions for a microprocessor having a plurality of function units |
5953736, | Apr 23 1997 | Oracle America, Inc | Write barrier system and method including pointer-specific instruction variant replacement mechanism |
6052699, | Dec 11 1996 | WSOU Investments, LLC | Garbage collection without fine-grain synchronization |
6094663, | Mar 31 1998 | Apple Computer, Inc.; Apple Computer, Inc | Method and apparatus for implementing atomic queues |
6098089, | Apr 23 1997 | Oracle America, Inc | Generation isolation system and method for garbage collection |
6101580, | Apr 23 1997 | Oracle America, Inc | Apparatus and method for assisting exact garbage collection by using a stack cache of tag bits |
6125434, | May 19 1998 | Northrop Grumman Systems Corporation | Dynamic memory reclamation without compiler or linker assistance |
6199075, | May 30 1997 | Oracle America, Inc | Method and apparatus for generational garbage collection of a heap memory shared by multiple processors |
6308319, | Feb 22 1999 | Oracle America, Inc | Thread suspension system and method using trapping instructions in delay slots |
6341293, | Jul 13 1994 | Apple Inc | Real-time computer "garbage collector" |
6421689, | Jun 30 1998 | Oracle International Corporation | Moderately conservative, mostly copying 2 space garbage collector in the nursery of a generational memory manager |
6446257, | Feb 04 1999 | HEWLETT-PACKARD DEVELOPMENT COMPANY, L P | Method and apparatus for pre-allocation of system resources to facilitate garbage collection |
6598141, | Mar 08 2001 | Microsoft Technology Licensing, LLC | Manipulating interior pointers on a stack during garbage collection |
6738893, | Apr 25 2000 | Intellectual Ventures Holding 81 LLC | Method and apparatus for scheduling to reduce space and increase speed of microprocessor operations |
6799266, | Dec 30 1999 | Texas Instruments Incorporated | Methods and apparatus for reducing the size of code with an exposed pipeline by encoding NOP operations as instruction operands |
6842853, | Jan 13 1999 | Oracle America, Inc | Thread suspension system and method |
6845385, | Jul 13 1994 | Apple Inc | Real-time computer “garbage collector” |
6862635, | Nov 13 1998 | CIT LENDING SERVICES CORPORATION | Synchronization techniques in a multithreaded environment |
6912553, | Dec 23 1998 | International Business Machines Corporation | Virtual machine memory management |
7013454, | Feb 22 1999 | Oracle America, Inc | Thread suspension system and method using trapping instructions |
20020029357, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Mar 13 2006 | Oracle America, Inc. | (assignment on the face of the patent) | / |
Date | Maintenance Fee Events |
Dec 17 2010 | ASPN: Payor Number Assigned. |
Apr 09 2014 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Apr 27 2018 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Jun 27 2022 | REM: Maintenance Fee Reminder Mailed. |
Dec 12 2022 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
Date | Maintenance Schedule |
Nov 09 2013 | 4 years fee payment window open |
May 09 2014 | 6 months grace period start (w surcharge) |
Nov 09 2014 | patent expiry (for year 4) |
Nov 09 2016 | 2 years to revive unintentionally abandoned end. (for year 4) |
Nov 09 2017 | 8 years fee payment window open |
May 09 2018 | 6 months grace period start (w surcharge) |
Nov 09 2018 | patent expiry (for year 8) |
Nov 09 2020 | 2 years to revive unintentionally abandoned end. (for year 8) |
Nov 09 2021 | 12 years fee payment window open |
May 09 2022 | 6 months grace period start (w surcharge) |
Nov 09 2022 | patent expiry (for year 12) |
Nov 09 2024 | 2 years to revive unintentionally abandoned end. (for year 12) |