KR100502380B1 - Write barrier system and method including pointer-specific instruction variant replacement mechanism - Google Patents

Abstract

Pointer-specific instruction variant replacement schemes facilitate the correct write barriers, that is, write barriers that are unique to the pointer store and transparent to the non-pointer store, and pointer store-specific instruction replacements are intergenerational in some implementations that are interested in a particular garbage collection method or combination of methods. To provide an exact barrier unique to a particular set of pointer stores, where accurate identification of the pointer store does not require in-line encoded tags in the collected memory store and requires non-standard word sizes to support such tags. In one embodiment, the non-fast to fast translator cache provides pointer specific store instruction replacement, and in another embodiment, the self-modifying code provides pointer specific store instruction replacement and the pointer-specific instruction variant of the present invention. Provided according to the replacement structure Exemplary write barriers include multiple garbage collection methods, including stored set-based methods, card-marking type methods, write barrier-based copy collector methods, mark-sweep methods, as well as combinations and generationally collected memory spaces. Enables a garbage collector implementer with support for combinations including a train algorithm type method of managing the maturity of the garbage collection page, such as a garbage collection page mask or intergenerational pointer to determine whether to trap The non-pointer store can be removed from the set of stores that find a value for the store trap matrix, and such write barriers can also remove the non-pointer from the stored set or card table store for scanning the collection time of the modified portion of the collected generation space. Remove entries associated with the store That is characterized.

Description

WRITE BARRIER SYSTEM AND METHOD INCLUDING POINTER-SPECIFIC INSTRUCTION VARIANT REPLACEMENT MECHANISM

TECHNICAL FIELD The present invention relates to garbage collection, and more particularly, to a method and system for separating generations in a garbage collector.

Traditionally, most programming languages have left the programmer with the responsibility of dynamically allocating and deallocating memory. For example, in the C programming language, memory is allocated from the heap by a malloc procedure (or a variant thereof). Given a pointer variable 'p', execution of the machine instruction corresponding to the statement p = malloc (sizeof (SomeStruct)) results in a memory object of the size needed for the pointer variable 'p' to represent the SomeStruct data structure. To indicate the newly allocated storage area. After use, the memory object identified by the pointer variable 'p' can be deallocated or freed by calling free (p). Pascal and C ++ languages provide similar tools for explicit allocation and deallocation of memory.

Unfortunately, dynamically allocated storage becomes unreachable unless a reference or pointer to that storage remains within the root reference location set for a given computer use. Memory objects that are no longer reachable and free are called garbage. Similarly, storage associated with memory objects can still be deallocated with reference. In this case, a dangling referencc was created. In general, it can be difficult to accurately manage dynamic memory. In most programming languages, heap allocations are required for the remaining data structures in the procedure that created the suspension reference. If these data structures are passed on to additional procedures or functions, it is difficult or impossible for the programmer or compiler to determine at what point it is safe to deallocate them.

Because of this difficulty, garbage collection, that is, automatic reclamation of heap-allocated storage after being last used by a program, may be an attractive alternative model of dynamic memory management. Garbage collection is a JAVA ^TM language (JAVA is a trademark of Sun Microsystems, Inc.) that exhibits less data sharing, lazy execution and generally less predictability of execution order than the procedural language, Prolog, Lisp, Smaltalk, Scheme, Eiffel, It is particularly attractive for functional languages such as Dylan, ML, Haskell, Miranda, and Oberon. See Jones & Lins, Garbage Collection: Algorithms for Automatic Dynamic Memory Management, pp 1-41, Wiley (1996) for a discussion of garbage collection and classical algorithms for it.

Three classic garbage collection methods are reference counting, mark-sweep, and copying storage reclamation. The first reference counting is based on continually counting the number of references, such as a pointer, for each memory object in the active memory object or root reference location. When a new memory object is allocated and a pointer is assigned to it, the reference count of the memory object is set to one. Then, each time a pointer is set to reference the memory object, the reference count of the memory object is incremented. If the reference to the memory object is deleted or overwritten, the reference count is decremented. Memory objects with reference count '0' are unreachable and are collected as garbage. Implementation of the reference counting garbage collector typically includes additional fields, reference counts within each memory object, and includes support to increase and decrease the delete object and update pointer functionality as part of the new object.

In contrast, the tracing collector method involves a reference chain traversal to memory to identify a live, ie referenceable memory object. One such tracing collector method is the mark-sweep method described above, wherein a reference chain is traversed to memory to identify and mark valid memory objects. Unmarked memory objects are garbage collected and returned to the free pool during the separate sweep phase. Implementations of the mark-sweep garbage collector typically include additional fields, such as mark bits, within each memory object. Mark-compact selectors add compaction to conventional mark-sweep methods. Compression relocates valid objects to achieve a beneficial reduction in fragmentation. The reference count method can also employ compression.

Another tracing method, the capping collection, divides memory into two semi-spaces, one containing current data and the other containing historical data. Coping garbage collection begins by reversing the roles of the two half regions. The capping collector then traverses a valid object in the old half area 'FromSpace' while copying the reachable object to the new half area 'ToSpace'. After all valid objects in FromSpace have been traversed and copied, a copy of the data structure exists in ToSpace. In essence, the capping collector collects valid objects among the garbage. A beneficial side benefit of the capping collector is that valid objects are compressed into ToSpace, thereby reducing fragmentation.

Generational approaches are based on the observation that (1) memory objects typically die young and (2) tracing methods consume significant resources to traverse, copy, or relocate relatively old objects. The generation garbage collection technique divides the heap into two or more generations, separates objects by age, and concentrates collection efforts (or at least more robust collection efforts) on young generation (s). Since the youngest generation can be small, the garbage collection associated with downtime can be kept short on average. Garbage collection within a generation may be a copy, mark-sweep, or other garbage collection method. In order to implement a generational collector, it is important that a mutator process, garbage collector, or any combination of the two defines an intergenerational pointer so that they can be treated as part of the root set by the garbage collector. . Mutators are the process of changing the graph of the reference chain via memory in the process of performing useful tasks in the computer system except garbage collection.

Intergenerational pointers typically occur through mutator process pointer stores or through the promotion of objects containing pointers. Promoted intergenerational pointers can easily be found by the collector process upon upgrade. However, because of the lack of an older generation for pointers and a survey of younger generations—a costly process—the pointer store must be trapped and written to search for inter-generational pointer storage. Barriers are well known and have been implemented in hardware, software, or with the support of an operating system (typically a paging system). By Jones & Lins, Garbage Collection: Algorithms for Automatic Dynamic Memory Management, pp 165-174, Wiley (1996) (Intergenerational Pointers, Write Barriers, Entry Tables, Memory Sets, Sequential Store Buffers, Page Marking with Hardware Support, Virtual Page marking by memory support, card marking, and the like) are discussed.

If software techniques such as in-line code for pointer store checking are used, the runtime and inline code overhead can be very large. An example of a software write barrier is proposed by Ungar (David M. Ungar, Generation Scavenging: A Non-disturptive High Performance Storage Reclamation Algorithm, ACM SIGPLAN Notices, 19 (5), pp.157-167 (See 1984), it interferes to check if (1) the pointer is being stored and (2) the pointer is for a young generation object and is stored in an old generation object. If so, the address of the old generation object is added to the remembered set. Software barriers can impose large amounts of overhead on the operations in which they are applied. For example, a software store barrier provided by inline code adds additional instruction latency to check whether a pointer is being stored and whether the pointer is intergenerational and increases the overall volume of code, for example. Such code increases badly affect cache performance.

An alternative to the software barrier is to use a virtual memory page protection mechanism of the operating system to trap access of a protected page or to trap a access to a page map that potentially contains an object with an updated intergenerational pointer field. Is to use page modification dirty bits. Such techniques typically defer the identification of pointer stores among all stores, and more specifically, the generation of pointer stores between generations until collection time. However, virtual memory page sizes are generally not well suited for garbage collection services. For example, pages tend to be larger than objects and virtual memory dirty bits write arbitrary changes to related pages rather than just pointer stores. As a result, the cost of page navigation for intergenerational pointers can be high.

Another alternative to the inline code software write barrier is the support of a hardware barrier. Although many write barrier implementations do not distinguish between pointers and non-pointer stores, instead write all writes by postponing pointer checks from generation to collection time, but the widespread use of hardware support for garbage collection in Symbolics 3600 allows for page marking. The technique was implemented efficiently. Three characteristics of the Symbolics 3600 make this workable. First, the hardware write barrier ignored all words that were not pointers to generation data. Each time a reference to a generation memory is stored in a page, the write barrier hardware sets the garbage collection page corresponding bit. Second, because the pointer words can always be distinguished using tags from non-pointer words, the tagged architecture eliminates the need to consider object boundaries while performing collection time checks for pointers between generations. The Symbolics 3600 accommodates two-bit major data type tags, four-bit minor tags, and 28-bit addresses in one 36-bit word. Finally, since the page is 256 words smaller than a typical virtual memory page, the page can be quickly retrieved at collection time. Jones & Lins, Garbage Collection: Algorithms for Automatic Dynamic Memory Management, pp. 169-170, Wiley (1996) (discussing page marking by hardware on Symbolics 3600), and Moon, Architecture of the Symbolics 3600, In See Proceedings of the 12th Annual International Symposium on Computer Architecture, pp. 76-83 (1985) (discussing the stored representations of objects).

The process of identifying intergenerational pointers requires a significant acquisition time search. One improvement is to divide the collected memory space (eg the heap) into smaller areas called cards. Card marking offers several advantages if the card is of the correct size. Since they are smaller than the virtual memory pages, the amount of collection time search can be reduced. On the other hand, the amount of space occupied by the card table is less than necessary for the word-by-word marking technique. In general, each time a word in the card changes, the bit is set unconditionally. The card marking collector must search for dirty cards for intergenerational pointers at collection time. The cost of searching for a card is proportional to the size and number of cards marked rather than the number of stores executed since no duplication occurs. See Wilson and Moher, Design of the Opportunistic Garbage Collector , ACM SIGPLAN Notices, 24 (10), pp. 23-35 (1985).

Generational approaches are very effective in reducing overall garbage collection time and most collection techniques may not be disruptive, while older generations can be disruptive. To collect these older generation objects in a non-destructive way, Hudson and Moss proposed an algorithm that handles a finite size region of mature object space in each collection. The algorithm increases in nature and ensures that any garbage is ultimately collected. Hudson and Moss use a train inference method with a train representing a group of carriages maintaining a link structure and a carriage representing a limited size area to explain the solution to the problem. The system is efficient in that it does not rely on special hardware or virtual memory mechanisms. By Hudson and Moss, Incremental Collection of Mature Objects , Proceedings of International Workshop on Memory Management, St. See Malo France (16-18 September, 1992).

Summary of the Invention

The present invention provides a system, a method for facilitating the execution of garbage collection, and a computer program for implementing such a system, method, and apparatus. In particular, the present invention provides a pointer-specific instruction variant replacement mechanism that facilitates an accurate write barrier, that is, a write barrier specific to the pointer store and transparent to the non-pointer store. Such a write barrier removes the non-pointer store from a set of stores that are negatively evaluated against, for example, a generational pointer store trap matrix or garbage collection page mask to determine whether to trap. . Such a write barrier also removes entries associated with non-pointers from the stored set or card table store during collection time searching for changed portions of the collected generation space.

The write barrier provided in accordance with the pointer-specific instruction variable replacement mechanism of the present invention includes a memory set based method, a card marking type method, a write barrier based capturing method, a mark-sweeping method, etc., as well as a combination and train algorithm type method thereof. The Garbage Collector Launcher, which supports a wide variety of garbage collection methods, including combinations, provides for the management of the mature portion of the memory space that has been collected for generations.

Pointer store specific instruction replacement allows some implementations in accordance with the present invention to provide accurate barriers specific to a particular intergenerational pointer store set involved in a particular garbage collection method or combination of methods, including the garbage collection method described below. Accurate verification of pointer stores here does not require collected memory storage and inline encoded tags, and does not require non-standard word sizes to support these tags. In one embodiment, the non-quick to quick translator cache provides pointer specific store instruction replacement. In another embodiment, the self modifying code provides pointer specific store instruction replacement.

According to one embodiment of the invention, an apparatus includes a virtual machine command processor, an instruction replacement component of the virtual machine command processor, and a write barrier. Instructions executable by the virtual machine instruction processor include program occurrences of store instructions. The instruction replacement component detects the store instruction and selectively replaces the specific program occurrence of the store instruction with a pointer-specific store instruction if the store target field of the particular program occurrence is resolved to a pointer type field. The write barrier is provided by the execution of the pointer-specific store instruction in the virtual machine instruction processor. In a further embodiment, the instruction replacement component includes a translator cache coupled to the instruction path of the virtual machine instruction processor. The resolution of the store target field is triggered by the translator cache in response to a mismatch indication of a program occurrence identifier. The translator cache caches a pointer-specific variant of the store instruction and associates the program occurrence identifier with it if the analysis indicates that the type of the store target field is a reference. In yet another additional embodiment, the instruction replacement component replaces a particular program occurrence of the store instruction by modifying an image in memory of a particular program occurrence of the store instruction.

In various embodiments, the virtual machine instruction processor may alternatively comprise a hardware processor or a software program executable on a hardware processor that directly executes at least a subset of the instructions, wherein the store instruction and the pointer-specific store instruction are stored in the It can be executed by a software program.

In another embodiment according to the present invention, a method for filtering a pointer store comprises a pointer-specific store based on detecting a program occurrence of a store instruction and an analysis of store target field type information for the program occurrence of the store instruction. And optionally replacing the program occurrence of the store instruction. Execution of the pointer-specific store instruction includes selective trapping according to the contents of the garbage collection configuration store.

In a further embodiment, the method includes executing a pointer-specific store instruction and selectively trapping execution according to the first content of the garbage collection configuration store. The garbage collection configuration store programmatically encodes a write barrier into a selected intergenerational pointer store. In yet another further embodiment, the method includes executing the pointer specific store instruction and selectively trapping the execution according to the second content of the garbage collection configuration store. The garbage collection configuration store programmatically encodes a write barrier to a garbage collection page boundary across the pointer store.

In yet another additional embodiment, the selective replacement includes performing a lookup in an instruction translator cache that uses a unique identifier for a program occurrence of the store instruction. If the unique identifier matches an entry in the instruction translator cache, it replaces the pointer-specific store instruction associated with it. In another embodiment, the selective replacement includes modifying an image in memory of a particular program occurrence of the store instruction.

Those skilled in the art will appreciate the various objects, features and advantages of the present invention with reference to the accompanying drawings.

1 is a block diagram illustrating an embodiment of a virtual machine hardware processor that includes support for garbage collection occurrence separation in accordance with the present invention;

FIG. 2 illustrates a “build upon” relationship between software and hardware elements of a JAVA application environment that includes a hardware processor (FIG. 1) and software elements of an embodiment of JAVA virtual machine execution;

3 illustrates a number of possible additions to the hardware processor of FIG. 1;

4 illustrates the operation of a write barrier provided in accordance with an embodiment of the present invention for trapping intergenerational and card boundaries across a pointer store made by a mutator process running on the hardware processor of FIG.

5 illustrates an object ref format according to an embodiment of the present invention;

6A illustrates an object format according to an embodiment of the present invention;

6B illustrates an alternative coordinated object format, in accordance with an embodiment of the present invention;

7 illustrates one embodiment of a bytecode replacement cache used in accordance with the present invention to dynamically replace pointer-native bytecodes with pointer-specific bytecodes to facilitate trapping of intergenerational and card boundaries across a pointer store. Drawing, and

8 is a diagram illustrating an exemplary stored set based on a generation collector method that may be supported by structural support for garbage collection in accordance with the present invention.

Use of the same reference numerals in different drawings indicates similar or identical items.

.

Description of the Preferred Embodiment (s)

Detailed description of the best mode for carrying out the invention is described as follows. This description is intended to illustrate the invention and should not be understood as limiting it.

The structural support described herein for the isolation of garbage collection generations includes intergenerational pointer store trap matrix, object reference generation tagging, write barriers in response to the intergenerational pointer store trap matrix, and object reference generation tagging, garbage collection trap handlers. ) And a pointer-specific instruction with a write barrier to facilitate selective dynamic replacement of pointer non-unique instructions.

In general, embodiments in accordance with the present invention may utilize various aspects of structural support for segregating generations in a garbage collected system. Such structural support may be provided in hardware, software, or a combination of hardware and software, but embodiments in which the structural support is provided substantially in hardware will typically provide improved performance and reduced memory requirements. . For this reason, an exemplary hardware virtual machine instruction processor embodiment is described herein. However, those skilled in the art will include implementations based on software (eg, interpreters, just-in-time compilers, etc.) implementations of virtual machine instruction processors that fall within the scope of the appended claims based on this description. It will be appreciated that alternative embodiments may be made.

JAVA virtual machine command processor embodiment

1 includes support for a finite downtime for relocating garbage collection in accordance with the present invention, and of a virtual machine instruction processor 100, hereinafter hardware processor 100, which directly executes a processor architecture independent of JAVA virtual machine instructions. An exemplary hardware embodiment is shown. The performance of the hardware processor 100 in executing virtual machine instructions is usually higher than a high-end CPU that translates the same virtual machine instructions with a software JAVA interpreter, such as an Intel PENTIUM microprocessor or Sun Microsystems ULTRASPARC processor. OK, (ULTRASPARC is a registered trademark of Sun Microsystems, Mountain View, California, and PENTIUM is an Intel registered trademark of Sunnyvale, California). In addition, the performance of the hardware processor 100 is better than some high-end CPUs with a JAVA JIT compiler. Hardware processor 100 is inexpensive and exhibits low power consumption. As a result, the hardware processor 100 is suitable for portable applications.

The hardware processor 100 substantially provides a hardware store of 25-50 Kbytes of memory, for example read only memory (ROM) or random access memory (RAM), the other required by the software interpreter is removed or alternatively. Can be assigned as Hardware support for garbage collection reduces inline code for garbage collection (e.g., read and / or write barriers provided by the compiler), facilitates efficient use of limited memory, and reduces garbage collection overhead and downtime. It provides additional benefits for implementing JAVA virtual machines with limited memory. In an environment involving other low-power, low-cost applications and portable devices, such as, for example, Internet chips for cellular applications, cellular phone processors, other communications integrated circuits or embedded processors, where the use of large memory is prohibited, hardware processors 100 is advantageous.

Even in large memory environments, hardware support for garbage collection reduces the overhead associated with implementing barriers, promotes improved memory efficiency, and reduces downtime for garbage collection. In particular, the hardware processor 100 provides advantages for garbage collection methods and implementations with respect to JAVA virtual machine implementations. However, one of ordinary skill in the art, based on this description, will be able to identify variations on other non-JAVA virtual machine implementations as well as other JAVA virtual machine implementations including, for example, translated JIT compiler JAVA virtual machine implementations.

As used herein, a virtual machine is an abstract computing machine that has a set of instructions and uses various memory regions like a real computing machine. The virtual machine specification defines a set of processor structures that are independent of the virtual machine instructions executed by the virtual machine implementation. In general, the virtual machine implementation may be hardware (such as in the case of hardware processor 100, for example), software (such as in the case of translated JIT compiler implementations), or a combination of hardware and software. have. Each virtual machine command defines a specific action to be executed. The virtual machine does not need to understand the computer language used to generate the virtual machine instructions or the underlying implementation of the virtual machine. You only need to understand the specific format for the virtual machine instructions. In one embodiment, the virtual machine command is a JAVA virtual machine command. Each JAVA virtual machine command includes one or more bytes that encode a command that identifies information, operands, and other necessary information.

In this embodiment, hardware processor 100 (FIG. 1) processes the JAVA virtual machine instruction that includes bytecode. The hardware processor 100 executes most of the bytecodes directly. However, the execution of some bytecodes is implemented through microcode. Lindholm & Yellen, The JAVA ^™ Virtual Machine Specification (Addison-Wesley, 1996), ISBN 0-201-63452-X, incorporated herein by reference, includes an exemplary JAVA virtual machine instruction set. The specific virtual machine instruction set supported by the hardware processor 100 is not an important aspect of the present invention. However, in view of the above virtual machine instructions, those skilled in the art can modify the present invention for a particular virtual machine instruction set or for changing to the JAVA virtual machine specification.

In one embodiment, the hardware processor 100 includes an I / O bus and memory interface unit 110, an instruction cache unit 120 including an instruction cache 125, and a non-high-speed translator cache 131. The command decode unit 130, the integrated execution unit 140, the stack management unit 150 including the stack cache 155, the data cache unit 160 including the data cache 165, and the program counter and trap control. Includes logic 170. Support for the garbage collection feature described herein basically provides some additional support for program counter and trap control logic 170 (e.g., support for forcing the program counter to the next JAVA virtual machine instruction following the trapping store). It is present in the register 144 and the integer unit 142 of the execution unit 140 having a). In one embodiment, the fast-fast translator cache 131 facilitates pointer uniqueness for the hardware write barrier logic of the integer unit 142. These units are described below.

FIG. 2 illustrates, for example, a "established" relationship between software and hardware components of a JAVA application environment, such as partly defined by hardware processor 100 (FIG. 1), and partly executable on that processor. . JAVA application / applet software 210 includes AWT class 241, net and I / O class 242, and JAVA OS window 243, JAVA OS graphics 248, TCP 244, NFS 245, UDP. Software configuration including JAVA bytecode in one embodiment, defining an applet / application programming interface 220 including 246, IP 247, Ethernet 222, keyboard and mouse 221 software components. Use elements In the embodiment of FIG. 2, the JAVA OS graphics 248 and Ethernet 222 software components also include extended bytecodes other than those defined by the baseline JAVA Virtual Machine Specification. The components of the embedded application programming interface (EAPI) 230 include the hardware and software components of the JAVA virtual machine implementation 250 and the base class 231 according to the JAVA Virtual Machine Specification.

JAVA virtual machine implementation 250 includes hardware processor 100 and executable trap code thereon to evaluate JAVA virtual machine instructions. The JAVA virtual machine implementation 250 also includes extended bytecode (e.g. garbage collection), such as class loader 252, bytecode checker 253, thread manager 254, and garbage collector 251 software. Hardware pointer store bytecodes and access barriers described below in connection with the < RTI ID = 0.0 > and < / RTI > JAVA virtual machine implementation 250 includes implementation dependent portions as well as JAVA virtual machine specification compliant portion 250a. Although the JAVA virtual machine specification specifies that garbage collection is provided, the particular garbage collection method used is implementation dependent.

The structural characteristics of the garbage collection described herein in connection with the exemplary hardware processor 100 implementation of the JAVA virtual machine implementation 250 are particularly suitable for generation garbage collection methods. However, one of ordinary skill in the art, based on this description, will be able to understand the application of the limited downtime support of the present invention to reallocating collectors, including, for example, non-generation collector implementations, incremental mark-compression collectors, capping collectors, and the like. will be.

3A shows some possible additions to hardware processor 100 to create a more sophisticated system. Eight functions shown: NTSC encoder 310, MPEG 302, Ethernet controller 303, VIS 304, ISDN 305, I / O controller 306, ATM assembly / reassembly 307 And circuitry supporting any of the wireless links 308 may be integrated on the same chip as the hardware processor 100 of the present invention.

Those skilled in the art will also recognize a wide variety of computer systems incorporating the hardware processor 100 that includes embodiments of the hardware processor 100 having any of the additional circuits described above. Exemplary computer system 300 embodiments include a physical memory store (eg, RAM and / or ROM), a computer readable medium access device (eg, disk, CD-ROM, tape, and / or memory technology based computer). Readable medium access devices, etc.), input / output device interfaces (eg, interfaces for keyboard and / or pointing devices, display devices, etc.) and communication devices and / or interfaces. Suitable communication devices and / or interfaces include those for network or telephone-based communications, for connection with telecommunications networks including terrestrial lines and / or wireless portions, such as public switched networks, private networks, and the like. In some embodiments of the invention, instruction streams (including JAVA bytecodes) are transmitted and / or received for execution by hardware processor 100 via the communication device or interface.

Structural Support for Garbage Collection

The hardware processor 100 provides structural support for a variety of garbage collection methods, including generation collector methods implemented as garbage collection software executable by itself. In particular, hardware processor 100 includes programmable store filtering, tagged object references and object header formats, and extended bytecode support.

Programmable Store Filtering

4 illustrates one embodiment of a supervisor writeable register GC_CONFIG that supports programmable filtering of the store for the heap. With reference to FIG. 1, register GC_CONFIG is contained in register 144 and accessible to execution unit 140. In one embodiment, the 12-bit register GC_CONFIG defines the field GC_PAGE_MASK, which is used to select the page size for inter-page pointer store checks. The 12-bit field GC_PAGE_MASK is used as bits 23:12 of the 32-bit garbage collection page mask with an additional 8 more valid bits defined as 0x3F and 12 less valid bits defined as 0x000. The generated 32-bit garbage collection page mask is used to form a store barrier for the pointer store across the programmable garbage collection page boundary. The store data value and the objectref target of the pointer store (for example, the aputfield_quick command that operates on the value and objectref that resides above the operand stack shown in the stack cache 155) are efficiently masked by the 32-bit garbage collection page mask. , value (objectref) is compared to determine if it points to a garbage collection page different from where the target object exists. In this manner, the garbage collection page size is independent of the virtual memory page size. In addition, garbage collection pages can be provided in computer system and operating system environments such as low cost, low power portable applications or applications for Internet devices without virtual memory support. In the embodiment of Figure 4, based on this description, appropriate variations to other garbage collection page sizes and size ranges will be apparent to those skilled in the art, but register GC_CONFIG allows programmatically defining garbage collection page sizes in the range of 4 KBytes to 8 MBytes. do.

The register GC_CONFIG also includes a field WB_VECTOR that programmatically defines the inter-generation pointer store trap matrix. The field WB_VECTOR encodes a pointer data generation associated with the store data value and a generation pair that the pointer store having a target object generation associated with its objectref target traps. In the embodiment of FIG. 4, WB_VECTOR specifies that the garbage collection trap defines a 4x4 matrix of 1-bit representations for the desired pointer data and the target object generation pair. Other embodiments may define larger or smaller matrices and optionally encode additional states (eg no_trap, gc_notify2 and gc_notify3).

Referring to the embodiment of FIG. 4, the 2-bit tag of the target object objectref is associated with two tag bits of value stored therein to form a 4-bit index in the field WB_VECTOR. Each 2-bit tag encodes household member information as described below. The indexed bit of the field WB_VECTOR then encodes whether the write barrier traps the corresponding pointer store. The field WB_VECTOR is used for all intergenerational pointer stores (that is, all pointer stores where the pointer data generation and the target object generation are not the same), all pointer stores (not only between generations, but within one generation), and newer generation pointer stores (that is, older ones). Programmatically to encode trappings, such as storing younger generation pointers into generation objects). In general, any complex trapping for generation pairs is supported. Although up to four generations are supported in the embodiment of FIG. 4, those skilled in the art will be able to determine appropriate variations for a larger number of generations based on this description.

In one embodiment, field GC_PAGE_MASK and field WB_VECTOR programmatically define the operation of the write barrier for the pointer store. In particular, as described in more detail below, extended bytecode support provided by the hardware processor 100 causes the write barrier to identify a pointer store in a non-pointer store, and the fields GC_PAGE_MASK and WB_VECTOR are also directed to the hardware processor 100. Allow programmatically filtering the write barrier to trap a programmatically defined set of pointer stores. However, alternative embodiments may hold advantageously accurate identification of the pointer storage provided by the hardware processor 100's extended bytecode support while still using the explicit set of pointer storage that is programmatically defined in conventional barrier implementations. Can be.

4 illustrates programmable stear filtering support with respect to four collected memory regions 450. The garbage collector process 420 includes bytecode that can be executed by the hardware process 100 to implement a generation collector in which the stored set 460 records the young generation pointer store created by the mutator process 410. do. The contents of the inter-generation pointer store trap matrix 470 correspond to the contents of the field WB_VECTOR and encode the write barrier into the young generation pointer store. As described below, the encoded tag includes an intergenerational pointer store trap matrix 470 for generations associated with the store data pointer value and generations associated with the objectref target of the pointer store instruction (ie, the aputfield_quick instruction) of the mutator process 410. Used to index into Based on the contents of the inter-generated pointer store trap matrix 470 elements so indexed, the write barrier 430 invokes a garbage collection trap handler (gc_notify) 440 so that the tags associated with the value and objectref are for the young generation object. Trap the aputfield_quick pointer store to indicate that the reference is stored in an old generation object.

Based on the description herein, one of ordinary skill in the art would appreciate that a garbage collection trap handler that supports programmatically selected specific store filtering provided by the intergenerational pointer store trap matrix 470 (ie of field WB_VECTOR) and / or the contents of field GC_PAGE_MASK. It will identify various suitable implementations for 440. In one embodiment according to the contents of the inter-generation pointer store trap matrix 470 (FIG. 4), the garbage collection trap handler 440 may store stored set data structures (e.g., generation 1, of collected memory region 450). And stored sets 461, 462, and 463 corresponding to 2, and 3, respectively). The bytecode executable by the hardware processor 100 to store information about the trapping store.

In another embodiment, the contents of the intergenerational pointer store trap matrix 470 are defined to be programmable to trap all pointer stores (intergenerational or otherwise). An alternative card marking type embodiment associated with garbage collection trap handler 440 includes bytecode that may be executed by hardware processor 100 to store information about the trapping store in a card table data structure. In contrast to conventional card marking implementations, the structure for garbage collection described herein supports the hardware processor 100 to distinguish between a pointer store and a general store, and to distinguish between a generational pointer store and a general pointer store. For this reason, in another card marking type embodiment, the content of the intergenerational pointer store trap matrix 470 is defined to be programmable to trap only intergenerational pointer store.

In stored set style embodiments and card marking style embodiments, extended bytecode support allows the hardware processor 100 to correctly identify a pointer store among non-pointer stores as described in more detail below. In addition, programmatically filtering the stur to the heap provided by the inter-generation pointer store trap matrix 470 (i.e., by field WB_VECTOR) and the write barrier 430 may cause the hardware processor 100 to mute the collection time. Data process 410 allows defining an intergenerational pointer store at store time. For this reason, the term card marking is described as the type of storage (ie, card table) provided by the embodiment of the garbage collection trap handler 440 for use by the collector process 420 during collection. The use of the term "card marking" does not mean that all stores need to be trapped regardless of whether pointer or character data is stored.

4 also shows support for garbage collection pages based on the trapping of pointer stores. The field GC_PAGE_MASK provides a programmable mask to compare the store data pointer value with the objectref target of the pointer store instruction (ie, the aputfield_quick instruction). The write barrier 430 traps the pointer store if the garbage collection pages for value and objectref do not match. Additional storage filtering is provided by the field GC_PAGE_MASK and the write barrier 430 is implemented by the Hudson train algorithm (R. Hudson and JEB Moss, Incremental Garbage Collection for the oldest generation) by the implementation of the collector process 420. Mature Objects , Proceedings of International Workshop on Memory Management, St. Malo, France, 16-18, Sept. 1992) are particularly useful for implementing the collector process 420 on a hardware processor 100 employing. Those skilled in the art will recognize the appropriate implementation in which the garbage collection page size defined by the field GC_PAGE_MASK is used to define the train "cars" according to Hudson's train algorithm.

By way of example, the syntax of the aputfield_quick bytecode and thus the operation of the hardware processor 100 is as follows:

Behavior: Setting a reference field on an object with garbage collection checks

form:

 aputfield_quick  offsetbyte1  offsetbyte2

Stack: ..., objectref, value

        ...

Description: The reference type objectref and reference type value pop out of the operand stack. The value is written to the offset specified in the class instance referenced by objectref. The value of the offset is (offset byte 1 < 8) |

Runtime exception: If the objectref is null, aputfield_quick throws a NullPointException.

The two leftmost digits of objectref and value are concatenated to form a 4-bit index. This index selects one bit from the 16-bit WB_VECTOR field in the GC_CONFIG register. If the selected bit is set, a gc_notify trap is generated.

index = ((objectref & 0xC0000000) »28) ｜ (value≫30)

if (GC_CONFIG.WB_VECTOR [index] = = 1)

generate gc_notify

Note: The opcode for this command was originally putfield, and the behavior for the field was determined to have a dynamic offset in the class instance data corresponding to the reference type field.

When the constant pool entry referenced by the putfield command is resolved, an offset for the field is generated and the type of the field is determined. The 16-bit offset replaces the two operand bytes of the original putfield instruction. The type of the field determines whether the putfield_quick, putfield2_quick, or aputfield_quick bytecode replaces the first putfield bytecode.

The syntax of the aputstatic_quick bytecode for setting a static reference field in a class (rather than a reference field in an object) and the operation of the hardware processor 100 accordingly is similar.

High Speed Garbage Collection Trap Handler

In one embodiment, fast processing of garbage collection is provided by vectored traps,

gc_notify (tt = 0x27), prioity = 17

Is implemented by trap control logic 170 to trigger an associated garbage collection trap handler 440 that includes bytecode executable by hardware processor 100. In one embodiment, whether it occurs in response to each page boundary cross pointer store or intergenerational pointer store, a single garbage collection trap handler 440 serves each of the garbage collection traps. Because garbage collection traps occur before the trapping store is complete, garbage collection trap handler 440 is garbage collected to prevent the hardware processor 100 from trapping indefinitely, such as a stored set or card table update. In addition to the collection function, it is necessary to mimic the trapping store. The garbage collection trap handler 440 then has to force the PC to a command following the store.

JAVA virtual machine instructions affected by garbage collection traps include aputfield_quick, aputststic_quick, aastore, anewarray, multianewarray, newarray, putfield, putstatic and new. Of these, only aputfield_quick, aputstatic_quick, and aastore need to perform garbage collection checks such as dynamic filtering in accordance with the contents of the fields WB_VECTOR and / or GC_PAGE_MASK. Others only need to know the garbage collection mechanism used, for example, the garbage collection mechanism used to properly initialize generation membership tags. In one embodiment, the aastore bytecode traps the copy routine and the aastore trap handler performs the appropriate garbage collection check. A simple trap handler implementation stores the arrayref on top of the operand stack in the aastore trap handler, and executes the dup, getfield_quick # 0, aputfield_quick # 0 bytecode sequences to perform appropriate checks and traps if necessary.

Tagged References and Object Formats

5 illustrates one embodiment of an object reference (objectref) as shown in hardware processor 100. Three bits of the objectref can be used for garbage collection hints. In particular, the field GC_TAG forms part of the index in the register field GC_CONFIG.WB_VECTOR to determine if the write barrier 430 traps the pointer store as described above. In the embodiment of FIG. 5, field GC_TAG encodes generation membership information for use by the write barrier 430 as described above. An additional processing bit H indicates whether the object is referenced by the objectref directly or indirectly through processing. The processing provides a reference method that facilitates the relocation of memory objects without massive updates of pointers (or objectrefs) to them, despite the cost of additional levels of bypass. These two fields are masked before being provided to the integer unit 142 (FIG. 1) of the hardware processor 100.

In one embodiment of the hardware processor 100, the object 600 is represented by a memory that includes a header portion 610 and an instance variable storage portion 620. 6A illustrates such an embodiment. The header portion 610 is a 32-bit word which itself comprises a method vector table base portion 612 representing the object class and a 5-bit additional storage area reserved for the synchronization status of the object and the information of the garbage collector. 614. Optionally, the second header word, eg, monitor pointer 616, may include the address of the monitor assigned to that object, thereby garbage all of the 5-bit additional storage 614 in the first header with. Make it available for collection information. In the embodiment of Figure 6A, the object reference (objectref) points to the location of the method vector table base portion 612 to minimize the overhead of the method call.

Three bits of header portion 610 may be used by a garbage collector, such as collector process 420. In the header portion 610, three lower bits (header 2; 0) and two upper bits (header 31:30) are masked off when the header is treated as a pointer. These three bits (headers 31:30, 2) can be used by the garbage collector to store information about the object 600. Bits 0 and 1 can be used to hold the LOCK and WANT bits for object synchronization. Alternatively, a second header word (eg, monitor pointer 616) may be provided to keep the object 600 in sync, leaving all five bits for garbage collection support. How the bits for garbage collection support are used depends on the particular type of garbage collection method that implements the collector process 420 and the garbage collection trap handler 440. Possible uses include mark bits and counter bits that age the object in generations. As noted above, in the second header word embodiment of header portion 610, five bits are available in a garbage collector, such as collector process 420.

In the embodiment of FIG. 6A, the instance variable storage portion 620 starts one word after the method vector table base portion 612 and includes the instance variables of the object 600. The rightmost digit bit of the objectref specifies whether the reference is adjusted (== 1) or not (== 0), and an alternative "processed" object format is shown in FIG. 6B. The processed reference is formed when the object 600 is created and processing of all subsequent references (ie, storage pointer 650b to access the object) is completed. This support is provided for some types of garbage collectors that reduce object relocation costs by copying processing rather than the underlying object storage, including for instance variables.

Extended bytecode support for dynamic replacement of pointer non-native bytecodes

The hardware processor 100 includes a feature for accelerating execution of the JAVA byte code by dynamically replacing the byte code supplied to the execution unit by the fast variable. However, as will now be described, the fast bytecode replacement feature dynamically relocates the data type non-unique storage operation to the pointer intrinsic storage operation bytecode such that the hardware processor 100 utilizes the implementation of a write barrier for garbage collection.

In one embodiment, the putfield and putstatic bytecodes for setting fields in an object or class are dynamically replaced with corresponding fast transforms (eg, putfield_quick, putfield2_quick, or aputfield_quick, and putstatic_quick, putstatic2_quick, or aputstatic_quick). The particular replacement bytecode depends on the type of field being operated on. For example, putfield bytecodes specified to operate on reference type fields are dynamically replaced by aputfield_quick bytecodes. Fast bytecode replacement utilizes loading and concatenating the work done initially when the associated non-fast bytecode is executed as described in the merged reference, but more importantly for garbage collection, pointer-specific fast bytecode Dynamic replacement of the locale allows a virtual machine instruction processor, such as a hardware processor, to identify pointer storage and non-pointer storage of data type non-unique store bytecodes. Replacing pointer-specific bytecodes reduces the trapping frequency for the store, since only pointer store bytecode variants (ie, aputfield_quick or aputstatic_quick) need to participate in the write barrier implementation.

One embodiment of dynamic bytecode replacement is now described with reference to FIG. FIG. 7 is a block diagram of a portion of hardware processor 100, which includes operand cache 723, instruction decoder 135, and non-high speed shown in stack cache 155 (see FIG. 1) in one embodiment. A high speed translator cache 131, a trap logic circuit 170, software search codes 31, 32, 33, and an execution unit 140. The non-high speed translator cache 131 includes an instruction and data processor 12 and an associated memory 14. In turn, the associative memory 14 comprises an instruction identifier section 18, a data set memory section 20, an input circuit 22 and an output circuit 24.

The instruction decoder 135 is coupled to receive an instruction flow, such as JAVA byte code, from the instruction cache unit 120. Although the present invention is described in the context of JAVA byte code, those skilled in the art will recognize variations for dynamically replacing other types of instructions in other virtual machine environments based on this specification. Although the bytecode replacement characteristic described hereinabove is generally applicable to instruction execution acceleration based on analysis of the execution time of instruction parameters as described more generally in the merged patent application, the specification facilitates the execution of a write barrier. It focuses on the hardware processor 100 for efficiently executing the dynamic replacement for the purpose, and the dynamic replacement of the pointer non-high speed bytecode with the pointer non-high speed bytecode different from the pointer non-high speed bytecode.

Referring to FIG. 7, the command decoder 135 provides a decoded bytecode on the bus 11 and provides a program counter (PC) value on the bus 13 corresponding to the decoded bytecode. These bytecodes and PC values are provided to execution unit 140 and instructions and data processor 12. In addition, the PC value is provided to the input circuit 22 of the associated memory 14. In general, each PC value uniquely identifies the corresponding program occurrence of the bytecode. The top entry of operand stack 723 is provided to instruction and data processor 12.

In the associative memory 14, the instruction identifier memory section 18 includes a number of (N) entries. Each of the N entries has a bytecode check value PC_0, PC_1, PC_2, PC_3,... It is possible to store the corresponding bytecode confirmation value, such as PC_N. Each bytecode check value stored in the command identifier memory section 18 corresponds to a different PC value. The width of the instruction identifier memory section 18 is selected corresponding to the width of the program counter.

The data set memory section 20 includes N entries such that each entry in the command identifier section 18 has an associated entry in the data set section 20. Each of the N entries in the data set memory section 20 is a data set DATA_0, DATA_1, DATA_2, DATA_3,... It is possible to store a data set such as DATA_N. As detailed below, each data set stored in the data set memory section 20 includes data for the execution of fast modification of the corresponding program occurrence of the bytecode. In one embodiment, data set memory section 20 is four 32-bit words wide. However, data set memory section 20 may have a different width in other embodiments.

The instruction and data processor 12 monitors the bytecode provided on the bus 11, and if the corresponding data set is fast accessible, then the current bytecode on the bus 11 can be executed in an accelerated manner. Determines if this is a bytecode. If so, the fast variant of the non-fast bytecode will be cached into the non-fast-translator cache 131 with the corresponding data set. In general, non-fast bytecodes may have zero, one, or faster variants. The JAVA virtual machine specification describes the following non-fast bytecodes: anewarray, checkcast, getfield, getstatic, instanceof, invokeinterface, invokespecial, invokestatic, invokevirtual, ldc, ldc_w, ldc2_w, multianewarray, new, putfield, and putstatic. In one embodiment of the processor 100 has a high speed variant. For non-fast storage oriented bytecodes, including putfield, putstatic, and aastore, parsing constant pool entries corresponding to target fields is equivalent to aputfield_quick (reference in object with garbage collection check if analysis points to pointer storage operation). Allows replacement with pointer-specific fast variants, such as setting fields) or aputstatic_quick (setting a static reference field in a class with a closed area reclaim check). If the analysis points to an object field of a different type than the reference (for example, non-pointer type), the replacement is putfield_quick (field setting on the object), putfield2_quick (long or double field setting on the object), putstatic_quick (in class Static field settings) or other fast variants such as putstatic2_quick (long or double static field settings in a class).

In general, if a corresponding data set is fast connectable, non-fast bytecodes capable of performing acceleration are referred to as non-fast bytecodes having fast transformations hereinafter. The non-fast bytecodes with fast modification form a subset of the bytecodes provided by the instruction decoder 135. The instruction and data processor 12 decodes the confirmation portion of the current bytecode to determine whether the current bytecode is a non-fast bytecode with fast transformation. Support for N program occurrences of non-fast bytecode with fast modification is provided by entries in the data set memory and the instruction identifier memory. Portions of this entry may be used for pointer-specific fast modification of non-fast storage oriented (but pointer non-unique) bytecodes for which corresponding program occurrences analyze pointer storage.

The non-high speed translator cache 131 operates as follows according to the current bytecode having the current PC value. The instruction decoder 135 provides the current PC value and the decoded current bytecode to the execution unit 140 and the instruction and data processor 12. The instruction and data processor 12 operates when the decoded bytecode is a fast transform, a fast transform load bytecode, or a non-fast bytecode with a retry bytecode. If the current bytecode provided on the bus 11 by the instruction decoder 135 is not a fast bytecode with a fast transform, fast transform load bytecode or retry bytecode, the instruction and data processor 12 Instead of responding to the bytecode, the current bytecode and current PC value are provided to the execution unit 140 for execution.

However, when the current bytecode is a non-fast bytecode with a fast variant, the instruction and data processor 12 operates in response to the current instruction. In one embodiment, bytecode putfield and putstatic operate data processor 12. In operation, the instruction and data processor 12 determines the state of the signal NO_MATCH appearing on line 21. Initially the instruction identifiers PC_0, PC_1, PC_2, PC_3,..., Stored in the instruction identifier memory section 18. PC_N is set to an invalid value. Alternatively, the 'valid' bit associated with the command identifier can be removed. In either case, the current PC value provided to the input circuit 22 does not initially match any of the command identifiers stored in the command confirmation memory section 18. Thus, the signal NO_MATCH appears. Current PC value and command identifiers PC_1, PC_1, PC_2, PC_3,... The absence of a match between PC_Ns indicates that the data set needed to execute the current bytecode is not currently stored in association memory 14. As a result, the instruction and data processor 12 must initially locate and retrieve the data set to allow replacement of the non-fast bytecode with a suitable fast variant.

In response to the non-fast bytecode analysis in which the current bytecode has a fast deformation and the signal NO_MATCH shown above, the instruction and data processor 12 represents the control signal TRAP. The control signal TRAP is provided to the trap logic 170. In response to the control signal TRAP, the trap logic 170 temporarily suspends the operation of the execution unit 170 and allows the corresponding software code portion 31, 32 or 33 to be accessed. The software code part that is accessed depends on the non-fast bytecode that caused the indicated control signal TRAP to appear.

In one embodiment, the trap logic 170 accesses the instruction cache unit 120 using the current PC value to identify the particular program occurrence of the bytecode that caused the control signal TRAP. A switch statement executed in software indicates execution into an appropriate software code section (according to the identified bytecode above). In alternative embodiments, other methods, such as trap vectors, may be used to direct execution to the appropriate software code portion.

Therefore, when the checked bytecode corresponds to the first bytecode INST_0, the switch statement causes the corresponding software code portion 31 to be accessed. In an embodiment, the first bytecode INST_0 is putfield and the second bytecode INST_1 is putstatic. When the identified bytecode corresponds to another arbitrary bytecode (e.g. denoted by INST_N), the switch statement causes the corresponding software code portion 33 to be accessed.

The software code sections 31, 32, ... 33 are byte code, INST_0 (e.g. putfield), INST_1 (e.g. putstatic)... Find and retrieve the data set needed to execute INST_N respectively. In other words, the software code sections 31, 32, ... 33 are byte code INST_0, INST_1,... For each occurrence of INST_N, a constant pool entry is analyzed. Since any non-fast bytecodes (e.g. putfield and putstatic) have a number of high-speed variants (e.g. putfield_quick, putfield2_quick, aputfield_quick, putstatic_quick, putstatic2_quick and aputstatic_quick), the corresponding software code portion also has a suitable high-speed variant. Choose. If the analysis of the corresponding constant pool entry indicates that a particular program occurrence of the storage oriented bytecode (eg putfield) points to a pointer store (eg if the type of the store target object field is a reference), then the pointer-specific fast variant ( For example, replacing with aputfield_quick is appropriate.

Software code portions 31, 32, ... 33 cause the retrieved dataset to be loaded into operand stack 723. The software code sections 31, 32, ... 33 provide the fast decoder load bytecode to the instruction decoder 135. The instruction decoder 135 decodes the fast transform load bytecode received after the retrieved data set is loaded into the operand stack 723. The decoded fast modified load bytecode is provided to the instruction and data processor 12 on the bus 11. The instruction and data processor 12 identifies each fast variant load bytecode present on the bus 11 and, accordingly, retrieves the corresponding data set previously loaded into the operand stack 723.

The instruction and data processor 12 then loads the retrieved data set and the current PC value into the associated memory 14. In one embodiment, the current PC value is written to the first entry of the command identifier memory section 18 with the command identifier PC_0 and the corresponding retrieved data set is written to the first entry of the data set section 20 with the data set DATA_0. Is recorded. The current PC value is routed from the instruction and data processor 12 to the memory section 18 on the bus 15. The method used to select a particular entry in memory 14 may be, for example, a random, last recently used (LRU) algorithm or a FIFO algorithm. The dataset is routed on the bus 17 from the instruction and data processor 12 to the dataset memory section 20.

After the current PC value and the retrieved data set have been entered into memory 14, instructions and data processor 12 cause the software code to retry the non-high speed instruction causing a control signal TRAP. At this time, the current PC value provided back to the input circuit 22 matches the command identifier (eg, command identifier PC_0) stored in the command identifier memory section 18. As a result, the signal NO_MATCH does not appear. Thus, the instruction and data processor 12 does not attempt to find and retrieve the corresponding data set via the trap logic 170 and the corresponding one of the software code portions 31, 32,... 33.

Since the current PC value matches the command identifier PC_0, the output section 24 delivers the corresponding data set DATA_0 to the execution unit 140. Thus, execution unit 140 retrieves the associated data set DATA_0 (including fast modified bytecodes) and current PC values into non-fast-fast translator cache 131. In response, the execution unit 140 executes the fast modified bytecode.

Once the data set associated with the non-fast bytecode having the fast value and the PC value is loaded into the associated memory 14, the special program occurrence of the non-fast bytecode with the fast variant is constant without the need to access the software code. It can then be run without analyzing the pool. In addition, for a special program occurrence of storage oriented bytecode, if the particular program occurrence results in a pointer store, a pointer specific fast variant (e.g. putfield-quick) is executed, and the special program occurrence is a non-pointer (or character value). Non-pointer fast transforms (eg, putfield_quick or putfield2_quick) are executed. In addition, since the non-high speed bytecode is not inputted in the program image, the non-high speed bytecode can be used in its original form. In addition, since the non-fast bytecodes are not duplicated, the non-fast bytecodes can be selectively stored in a read-only memory.

The following embodiment is a non-high-speed to facilitate pointer store specific implementation of the write barrier 430 to selectively trap the pointer store by the hardware processor 100, in particular the mutator processor 410 (FIG. 4). It will make the operation of the fast translator cache 131 more clear. The instruction decoder 135 initially receives a non-fast bytecode (e.g. putstatic) having a fast transform, where the special program occurrence of the non-fast bytecode has a corresponding PC value of 0x000100. Assuming that an occurrence of the special program of bytecode putstatic does not appear in the instruction identifier memory section 18, the current PC value 0x000100 causes the input circuit 22 to indicate the signal NO_MATCH. Corresponding to the analysis that the signal NO_MATCH and the bytecode putstatic are non-fast bytecodes with fast deformation, the instruction and data processor 12 represents the control signal TRAP. Trap logic 170 uses the PC value to identify the current bytecode as bytecode INST_1 (ie putstatic). Corresponding to the current bytecode identified by the bytecode INST_1, the software switch statement instructs the execution of the corresponding software code portion 32.

Software code section 32 then analyzes the constant pool entry associated with the store target object field, retrieves the data set needed to execute bytecode INST_1, and loads the data set into operand stack 723. . The software code portion 32 provides the fast decoder load bytecode to the instruction decoder 135. In response, the instruction decoder 135 provides the decoded fast transform load bytecode to the instruction and data processor 12. Instruction and data processor 12 retrieves the data set from operand stack 723 and loads the data set as data set DATA_0 into the first entry of data set memory section 20. Software code section 32 determines whether the store target object field is of type reference (i.e., whether a particular program occurrence of putstatic is a pointer store), and includes the appropriate pointer specific fast variant bytecode aputstatic_quick with data set DATA_0. do.

The instruction and data processor 12 further loads the current PC value 0x000100 into the first entry of the instruction identifier memory section 18 as the instruction identifier PC_0. The instruction and data processor 12 then displays the non-fast bytecode INST_1 (i.e. putstatic) and the current PC value 0x000100 on each bus 11,13. In one embodiment, the command and data processor 12 may obtain this by issuing a ret-from-trap bytecode return that transfers control back to the bytecode resulting in the control signal TRAP. At this time, the input circuit 22 confirms the correspondence between the current PC value and the command identifier PC_0. In response, the associative memory 14 provides the output circuit 24 with a data set associated with the instruction identifier PC_0 (i.e., the data set DATA_0 including pointer specific fast variant bytecode aputstatic-quick). The output circuit 24 transfers the data set DATA_0 to the execution unit 140 which executes the pointer specific fast modified bytecode aputstatic_quick.

Other non-fast bytecodes with fast modifications and other program instances of the same non-fast bytecodes that are subsequently received by the instruction decoder 135 are processed in a similar manner. For example, another program occurrence of the non-fast bytecode INST_1 (ie putstatic) with the associated PC value 0x000200 is the PC value 0x000100 stored in the instruction identifier section 18 as the instruction identifier PC_1, and the data set DATA_1. This is due to the data set associated with the command INST_1 being stored in the data set memory section 20. If the special program occurrence of the bytecode putstatic resolves to a character value store, then the data set associated with the instruction identifier PC_1 (i.e., data set DATA_1) will contain a fast variant bytecode such as putstatic2_quick rather than a pointer specific fast variant. Note that the data set associated with the first program occurrence of non-fast bytecode INST_1 (e.g. data set DATA_0) is not the same as the data set associated with the second program occurrence of non-high speed bytecode INST_1 (e.g. data set DATA_1). Be careful.

Non-high-speed bytecode 2 by analyzing the programs the occurrence of putstatic pointer-specific store bytecode aputstatic _{_} first program occurrence with a pointer Remarks significant store byte second program occurrence, hardware processor 100 to the code putstatic2_quick the quick - The fast translator cache 131 confines the write barrier 430 to the pointer store. As described above, through the evaluation of the bytecode aputfield_quick by the hardware processor 100, the write barrier (as implemented by the pointer-specific fast variant bytecode) concatenates the two leftmost digits of each of the objectref and value operands. By forming a 4-bit index. This index selects one bit from the 16-bit field WB_VECTOR in register GC_CONFIG. If the selected bit is set, a trap gc_notify is generated.

index = ((objectref & 0xC0000000) >> 28) ｜ (value >> 30)

   if (GC＿CONFIG.WB＿VECTOR [index] == 1)

       generate gc＿notify

In one embodiment of execution unit 140 (FIG. 1), the logic circuit for bytecode calculation is coupled to register GC_CONFIG (FIG. 4) and executes the logical representation. Those skilled in the art will recognize various suitable embodiments.

In another embodiment, the write barrier 430 (implemented by pointer specific fast variant bytecodes) supports both garbage collection page boundaries that intersect generational store trapping and pointer store trapping. As described above, the embodiment of the write barrier 430 forms a 4-bit index by concatenating the leftmost two bits of each of the objectref and store_data operands. This index selects one bit from the 16-bit field WB_VECTOR in register GC_CONFIG. If the selected bit is set, a trap gc_notify is generated. However, a second trigger is provided for the comparison of the masked portion of the objectref and store_data operand. The mask is programmablely defined by the GC_PAGE_MASK field of register GC_CONFIG, bit 27:16. The second trigger is protected by the garbage collection page enable bit GCE of the processor status register PSR.

if {(GC＿CONFIG [(objectref [31:30] ## store＿data [31:30])} == 1)

   OR ((PSR.GCE == 1) AND

((store＿data [31:12] & 0x3F ## GC＿CONFIG [27:16])! =

(objectref [31:12] & 0x3F ## GC＿CONFIG [27:16])}

             then trap

In one embodiment of execution unit 140 (FIG. 1), the logic circuit for bytecode calculation is coupled to register GC_CONFIG (FIG. 4) to implement the logical representation. Those skilled in the art will recognize various suitable embodiments.

An advantageous alternative embodiment of the write barrier 430 provides a mechanism for limiting garbage collection boundary crossing checks to certain generations or generations of collected memory space, typically the oldest generation. Transformed page check trapping expression, i.e.

if ((PSR.GCE == 1) |

((objectref [31:30] == store＿data [31:30]) &&

(GEN＿PAGE＿CHECK＿ENABLE [objectref [31:30]] == 1))) &&

((objectref [31:12] & 0x3F ## GC＿PAGE＿MASK)! =

(store＿data [31:12] & 0x3F ## GC＿PAGE＿MASK))

  then trap is

Generation tag bits (eg bits 31:30) of the objectref and store_data operand require the same. To allow flexibility for encoding the oldest generation, four otherwise unused bits (eg bits 31:28) of register GC_CONFIG can be used to encode field GEN_PAGE_CHECK_ENABLE. This 4-bit field indicates which generation (s) the trapping of the garbage collection page boundary crossing store is limited to. Those skilled in the art will recognize various suitable implementations, including the generation-specific garbage collection page boundary crossing store trapping, having the intergenerational pointer store trapping described above.

As described above, the operation of the non-fast translator cache 131 replaces the original bytecode putfield with the bytecode aputfield_quick determined to operate on a field with an offset in the class instance data corresponding to a field of reference type. . When a constant pool entry referenced by the putfield command is resolved, an offset for the field is generated and the type of the field is determined as reference. The 16-bit offset included in the corresponding data set DATA # 1 of the non-fast-fast translator cache 131 replaces the two operand bytes of the original putfield instruction. The type of field determined that the aputfield_quick bytecode replaces the original putfield bytecode rather than the putfield_quick or putfield2_quick bytecode. Depending on the contents of the fields WB_VECTOR and GC_PAGE_MASK of the register GC_CONFIG, one embodiment of the write barrier 430 (partially implemented by the fast variant bytecode aputfield_quick) may trap the pointer store as described above.

One embodiment of dynamic bytecode replacement for hardware processor 100 is described. Another embodiment of dynamic bytecode replacement is based on self-modifying codes. In view of the description of the non-fast-fast translator cache 131, self-modifying code embodiments have an advantage when the implementation of the cache is impractical or undesirable (e.g., due to cost). In such a case, the non-fast translator cache 131 may be cleared. Instead, the trap code, e.g., the software code section 31, 32, ..., writes directly into the instruction space so that subsequent execution of a particular program occurrence of the original non-high speed bytecode can evaluate the fast variant. By replacing the original bytecode with its appropriate variant. One embodiment of a self-modifying code based on a dynamic bytecode replacement mechanism is described in US Pat. No. 5,367,685.

Garbage Collection Example

The use of the above structural support for the garbage collection described above is now described in relation to the following three generation collector approaches: an embodiment of Ungar's memorized set generation collector, an embodiment of Wilson's card table based on the generation collector and a train of Hudson Collector based on algorithm.

Remembered Set-based Generational Collector

8 shows generation garbage collection using an Ungar stored set. Implementation of this garbage collection approach (eg, including write barrier 430, collector process 420, and garbage collection trap handler 440) may advantageously utilize the characteristics of hardware processor 100 in the following manner.

1. No need to trap all stores. In particular, only pointer stores in the heap need to be checked. The use of the aputfield_quick and aputstatic_quick bytecodes described above allows checking of these pointer stores only.

In addition, the store for the operand stack or local variable indicated in the stack cache 155 does not require a trap if the operand stack, local variable and static area are assumed to be part of the root set. The object reference indicated in the entry of the stack cache 155 may be identified as a pointer.

2. As described above, the write barrier 430 support of the hardware processor 100 traps if the objectref of the young generation object is stored as an old generation object.

3. In some embodiments, in an embodiment in which only two generations are supported in the collected memory space 850, the field WB_VECTOR of the register GC_CONFIG contains the value 0x5050. Only one bit (ie bit 30) of the field GC_TAG of the objectref is considered. In one embodiment, a value of 0 defines that the objectref points to an object in the young generation 810, while a value of 1 defines that the objectref points to an object in the old generation 820. In this embodiment, bit 31 can be effectively ignored. Embodiments for a greater number of generations will be apparent to those skilled in the art. According to the contents of the field WB_VECTOR, the write barrier 430 triggers a garbage collection trap handler 440 whenever a pointer from an old generation 820 object is stored as a young generation 810 object. In this embodiment, the PSR.GCE bit is set to 0, which disables the write barrier 430 operation based on the contents of the field GC_PAGE_MASK.

4. Trap conditions for the store

if {(GC＿CONFIG [(objectref [31:30] ## store＿data [31:30])} == 1)

   OR ((PSR.GCE == 1) AND

       ((store＿data [31:12] AND 0x3F ## GC＿CONFIG [27:16])! =

        (objectref [31:12] AND 0x3F ## GC＿CONFIG [27:16])}

             then trap

Where store＿data is a 32-bit pointer stored in the target object. objectref is the 32-bit pointer to the object from which the store is created.

5. When the hardware processor 100 traps, that is, when the write barrier 430 triggers the garbage collection trap handler 440, the execution of the hardware processor 100 jumps to the garbage collection trap handler 44. In one embodiment, garbage collection trap handler 440 stores information in stored set 830 and mimics a trapping pointer store.

6. During garbage collection, the object is the object promoted from the young generation 810 to the old generation 820, all the reference fields GC_TAG for the promoted object reflect that the promoted object is part of the older generation. Is updated.

Card Table Based Generation Collector

To implement a card based generation collector, the field WB_VECTOR in the register GC_CONFIG is set to 0xFFFF. This causes the write barrier 433 to trap all pointer stores for the heap and to trigger a trap handler, such as garbage collection trap handler 440. In this card-based generation information collection embodiment, garbage collection trap handler 440 performs additional storage on the card table data structure and mimics a trapping store. In contrast to the Wilson-based conventional card-based generation collector implementation, the above described embodiment only traps a pointer store. In another embodiment, the field WB_VECTOR in register GC_CONFIG is set to an appropriate value to define the trapping behavior of write barrier 430, which also corresponds only to intergenerational pointer stores. In this manner, acquisition time scanning may be limited to cards where inter-generation pointer stores occur. In this embodiment, the card table has the advantage of providing a deduplication function as opposed to the stored set embodiment described above.

Train algorithm based collector

Hudson's train algorithm is well known to allow non-destructive collection of the oldest generation of generation systems. Remembering references between different memory spaces ("cars") in the oldest generation uses a write barrier. In the implementation of hardware processor 100, these " cars " The field GC_PAGE_MASK defines the operation of the write barrier 430 for this kind of garbage collection algorithm. If the processor status register bit PSR.GCE is set to 1, all pointer stores beyond the garbage collection page boundary (defined as field GC_PAGE_MASK) cause the write barrier 430 to trigger the garbage collection trap handler 440. In this embodiment, the garbage collection trap handler 440 that manages the page ('cars') size is programmatically defined based on the field GC'PAGE'MASK in the register GC'CONFIG. In the above embodiment, a page area between 4 KBytes and 8 MBytes is supported.

Other collector

Several real-time garbage collectors have been developed that are dependent on write barriers. Implementations of these garbage collectors may utilize pointer-specific characteristics of the write barrier 430. Incremental mark-sweep collectors, such as proposed by Steele (see Guy L. Steele, Multiprocessing Compactifying Garbage Collection, Communications of the ACM, 18 (9) (1975)), also point to pointer-specific characteristics of the write barrier 430. It is available.

Although the present invention has been described with reference to various embodiments, these embodiments are illustrative and should not be construed as limiting the scope of the invention. Various modifications, changes, additions, and improvements to the above embodiments are possible. The present invention has been described with reference to embodiments in conjunction with a JAVA programming language and a JAVA virtual machine, but is not limited thereto, and includes systems, articles, methods and apparatus for a wide variety of processor environments.

In addition, although the present invention has been described in the form of hardware and software, the execution of the virtual machine instruction processor may be performed by intergenerational pointer store trap matrices, object reference generation tagging, intergenerational pointer store trap matrix and object reference generation tagging. Adopting a collection trap handler, and / or proper write barrier support can facilitate selective dynamic replacement of pointer non-unique instructions with pointer specific instructions. These and other variations, modifications, additions and improvements are possible without departing from the spirit of the invention.

Claims (40)

Virtual machine instruction processor; An instruction replacement component of the virtual machine instruction processor; And A write barrier provided by execution of a pointer-specific store instruction on the virtual machine instruction processor, The instructions executable by the virtual machine instruction processor include a program occurrence of a store instruction, the instruction replacement component detects the store instruction, and if the store target field of the particular program occurrence refers to a pointer type field. And replace a particular program occurrence of a store instruction with a pointer-specific store instruction. The method of claim 1, The instruction replacement component includes a translator cache associated with an instruction path of the virtual machine instruction processor, A reference of the store target field is triggered by the translator cache in response to a program occurrence identifier mismatch indication, The translator cache caches a pointer-specific modification of the store instruction and associates the program occurrence identifier with it if the reference indicates that the type of the store target field is a reference. The method of claim 2, The virtual machine instruction processor comprises a hardware processor adapted to directly execute at least a subset of the instruction, And wherein said translator cache is coupled between an execution unit of said hardware processor and an instruction decoder. The method of claim 1, And the instruction replacement component replaces the specific program occurrence of the store instruction by modifying an image in memory of the specific program occurrence of the store instruction. The method of claim 1, The virtual machine instruction processor comprises a hardware processor adapted to directly execute at least one subset of the instructions, The write barrier includes a logic circuit responsive to a garbage collection configuration register of the hardware processor, the logic circuit being used by the hardware processor to filter the garbage collection trap of the pointer-specific store instruction. Device. The method of claim 1, And wherein the virtual machine instruction processor comprises a software program executable on a hardware processor, wherein the store instruction and the pointer-specific store instruction are executable by the software program. The method of claim 6, The software program defines a garbage collection configuration storage device accessible thereto, The execution of the pointer-unique store instruction comprises obtaining a value of a hardware processor instruction that implements a logical operation to filter garbage collection traps of the pointer-specific store instruction in accordance with the contents of the garbage collection configuration storage device. Characterized in that the device. The method of claim 6, And the software program comprises an interpreter for the virtual machine instructions. The method of claim 6, And the software program comprises a just-in-time (JIT) compiler that incrementally compiles the virtual machine instructions into the hardware processor instructions. The method of claim 1, And said store command is a JAVA virtual machine bytecode. The method of claim 1, The store instruction is a non-fast bytecode with a first fast variant, And the pointer-unique command is the first fast variant. The method of claim 5, The garbage collection register is stored such that one of the components indicates whether the write barrier should trap the execution of a particular program occurrence of the pointer-specific store instruction given the store reference data and the generation tag associated with the store target object. And an inter-generation pointer store trap matrix representation having components corresponding to the target object and the store reference data. According to claim 1, The virtual machine command processor includes a garbage collection configuration store representation, The execution of the pointer specific store instruction comprises determining whether a particular program occurrence of the pointer-specific store instruction stores a boundary crossing pointer that is marked for trapping by the garbage collection configuration store. . The method of claim 13, The boundary crossing pointer is an intergenerational pointer, And the garbage collection configuration store includes an inter-generation pointer store trap matrix representation. The method of claim 13, The boundary crossing pointer is a garbage collection page boundary crossing pointer, And the garbage collection configuration store includes a garbage collection page mask representation. The method of claim 1, And an error handler responsive to said write barrier. The method of claim 16, And the error handler includes instructions for storing in a stored set. The method of claim 16, And the error handler includes instructions for storing in a card table. The method of claim 16, Further comprising a generation collector process of instructions executable by the virtual machine instruction processor, And the error handler includes instructions executable by the virtual machine command processor to store information identifying store data trapped in a data structure for use by the generation collector process. Detecting a program occurrence of a store instruction; And Selectively replacing the program occurrence of the store instruction with a pointer-specific store instruction based on a reference of store target field type information for the program occurrence of the store instruction, And executing the pointer-unique store instruction comprises an optional trapping step according to the contents of the garbage collection configuration store. The method of claim 20, Executing the pointer-specific store instruction; And Optionally trapping the execution step according to the first content of the garbage collection configuration store, And the garbage collection configuration store programmatically encodes a write barrier to a selected intergenerational pointer store. The method of claim 20, Executing the pointer-specific store instruction; And Selectively trapping said execution step in accordance with a second content of said garbage collection configuration store, And the garbage collection configuration store programmatically encodes a write barrier into a garbage collection page boundary cross pointer store. The method of claim 20, The store instruction is a non-fast bytecode with its first fast variant, And the pointer-unique store instruction is the first fast variant. The method of claim 20, Executing a non-pointer store instruction corresponding to a second program occurrence of the store instruction, And executing the non-pointer store instruction does not include an optional trapping step according to the contents of the garbage collection configuration store. The method of claim 24, The store instruction is a non-fast bytecode with its first and second fast variant, The pointer-native store instruction is the first fast variant, And wherein said non-pointer store instruction is said second fast variant. The method of claim 20, In response to the selective trapping, further comprising executing a trap handler. The method of claim 20, And responsive to the selective trapping, storing instructions that identify the store instruction target object in a stored set. The method of claim 20, And responsive to said selective trapping, storing information indicative of said store command target object in a card table. The method of claim 20, And wherein said detecting step matches a program counter value associated with said program occurrence of said store instruction with a stored program counter value. The method of claim 20, And wherein said selectively replacing comprises modifying an image in memory of said specific program occurrence of said store instruction. The method of claim 20, The optional replacement step is: Performing a search in an instruction translator cache using a unique identifier for the program occurrence of the store instruction; And If the unique identifier matches a first entry in the instruction translator cache, replacing the pointer-specific store instruction associated with it. The method of claim 31, wherein The optional replacement step is: If the unique identifier matches a second entry in the instruction translator cache, further comprising substituting a non-pointer store instruction associated therewith, And the execution of the non-pointer store instruction does not include an optional trapping step according to the garbage collection configuration store contents. The method of claim 31, wherein The optional replacement step is: If the unique identifier does not match any entry in the instruction translator cache, determining type information for a store target field of the program occurrence of the store instruction; Storing a result of said determining step in said instruction translator cache; And And retrying the performing search and the substituting step. The method of claim 20, Determining type information for a store target field of the program occurrence of the store instruction. The method of claim 20, And wherein the determining step comprises retrieving a data set associated with the store target field, wherein the data set includes the store target field type information. The method of claim 20, The determining step includes retrieving information including the store target field type information from a constant pool table associated with a store target object of the program occurrence of the store instruction, wherein the constant pool table is associated with the store target field. A method of filtering a pointer store, comprising a constant pool field. The method of claim 20, The determining step is: Retrieving a data set associated with the store target field; And Storing information from the pointer-unique store instruction and data set in an instruction translator cache. A method for filtering a mutator process pointer store in a virtual machine command processor, comprising: Selectively transforming a program occurrence of a pointer non-unique mutator store instruction into one of its non-pointer and pointer-specific variants; And Substantially trapping only the pointer-unique variation based on the correspondence of the operand of the pointer-uniform variation and the garbage collection configuration store contents, And wherein said modifying step is based on a runtime determination of a store target field type of said pointer non-unique mutator store. The method of claim 38, And continuing to the modifying step, and executing the pointer-specific modifying instead of the pointer non-unique mutator store instruction only for the modified program occurrence. A structural support for selectively trapping a pointer store in a virtual machine instruction processor having an executable mutator and garbage collector process, The structural support unit, Garbage collection configuration store; Instruction replacing means operably connected with an instruction path of the virtual machine instruction processor to replace a pointer non-unique instruction with its fast variant based on a change in target field type for the pointer non-unique instruction; And A write barrier provided by the execution of a pointer specific fast variant on the virtual machine command processor, If the target field type is a reference type, the fast transform is a pointer-specific fast transform, And the write barrier responds to the garbage collection configuration store.