System and method for facilitating unmanaged code participation in garbage collection6748503Abstract A system and method for facilitating unmanaged code participation in a memory management system employing a garbage collection system or service is provided. The invention provides for an unmanaged component to invoke a machine state capturing component that captures machine state (e.g., machine registers and stack pointer) into a machine state data structure and publishes the fact that the unmanaged component desires to participate in garbage collection pointer enumeration. The invention further provides for an unwind component to be invoked during garbage collection that determines register value(s) to facilitate participation in garbage collection pointer enumeration by the unmanaged component. As part of its participation in garbage collection, the unwind component can alter contents of the machine state data structure stored by the machine state capturing component. The invention further provides for an unmanaged component to invoke a machine state restoring component that restores the machine state (e.g., machine registers and stack pointer) saved by the machine state capturing component, which may have been altered by garbage collection, and to publish the fact that the unmanaged component no longer desires to participate in garbage collection pointer enumeration. Claims What is claimed is: Description TECHNICAL FIELD
allocate machine state data structure;
do {
if(machine state capturing component (&machine state data
structure) <> 0 then
return;
else
/* arbitrary work that can cause a garbage collection*/
} while (machine state restoring component <> 0)
The unmanaged component 110 allocates the machine state data structure 170 and invokes the machine state capturing component 120 passing a pointer to the machine state data structure 170. The machine state capturing component 120 is responsible for storing the current value(s) of the machine register(s) for use by the unwind component 160. The machine state capturing component 120 further publishes the fact that the unmanaged component 110 desires to participate in garbage collection pointer enumeration. Significantly, the captured machine state stored in the machine state data structure 170 is not the machine state that is needed to unwind from the unmanaged component 110 (e.g., some of the original machine register(s) may have been saved by the unmanaged compiler on entry to the unmanaged component 110, and can be in use for other purposes). Thus, a mechanism is needed to recover the machine state that will exist when the unmanaged component 110 returns from the state captured by the machine state capturing component 120. This is the purpose of the "then--return" branch in the in the pseudo-code above. The return statement is not intended to be executed at run time (e.g., the machine state capturing component always returns zero). The purpose of the "then" branch is to force the unmanaged compiler used to compile the unmanaged component 110 to generate native machine instruction(s) for restoring the machine register(s) prior to returning to the invoking routine. This instruction sequence will be used by the unwind component 160, if a garbage collection happens to map the captured machine state, into the machine state that will exist when the unmanaged component 110 returns. The garbage collection component 130 is responsible for performing garbage collection for the memory heap 140. It can be invoked either in response to operations in the unmanaged component 110 and/or asynchronously by other threads requesting a garbage collection. During the collection the garbage collection component 130 enumerates the stack, starting with the top method (e.g., program). Eventually it gets to the unmanaged component 110 and discovers the published information. By default the published information indicates that there are no GC pointers to report for the unmanaged component 110 itself (although it is within the scope of the present invention to have an API that allows the unmanaged component 110 to request that certain GC pointer(s) be reported). When the GC requests an unwind out of the unmanaged component 110, it is directed to the unwind component 160. The unwind component 160 maps the captured machine register(s) stored in the machine state data structure 170 back to the machine state that will exist when the unmanaged component 110 returns by examining the instructions generated by the "return" statement. For example, X86 machine instructions (e.g., generated by the unmanaged compiler) for the "then" branch could include: Test EAX, EAX JZ Epilog . . . Epilog: XOR EAX, EAX POP ESI POP EDI MOV ESP, EBP POP EBP RET 4 In this example, the unwind component 160 can determine that the unmanaged component 110 saved machine registers ESI and EDI at the top two stack locations pointed to by the ESP register in the captured machine state. The unwind component 160 can further determine that the unmanaged component 110 saved register EBP at the location pointed to by the EBP register in the captured machine state. Finally, the unwind component 160 can determine that the unmanaged component 110 saved register EBX was not altered (e.g., spilled) and thus should be the value in the captured machine state. Having this information, the unwind component 160 can perform the unwind operation(s) required by the garbage collection component 130. In this example, the unwind component 160 can report that register ESI is saved at the location pointed to by the captured stack pointer, register EDI is saved at the location just above ESI, register EBP is saved at the location pointed to by the captured EBP value, and, register EBX is saved at the location in the machine state data structure 170 stored by the machine state capturing component 120. Further, the unwind component 160 can report that the return from which the unmanaged component 110 was invoked is above the EBP value, and, the value of the stack pointer when the unmanaged component 110 returns will be four bytes above that location. Equipped with information from the unwind component 160, the garbage collection component 130 can perform garbage collection (e.g., via garbage collection pointer enumeration). Significantly during garbage collection, the garbage collection component 130 can alter garbage collection pointer(s) some of which may be stored in machine register(s). These updates happen to the location(s) reported by the unwind component 160. Thus, in the example above, the values on the stack for EDI and ESI might be updated, as well as the location in the machine state data structure 170 holding the captured value of EBX. The unmanaged component 110 can indicate its desire to no longer participate in garbage collection by invoking the machine state restoring component 150 passing a reference (e.g., pointer) to the machine state data structure 170. The machine state restoring component 150 is responsible for updating the register(s) value(s) saved from the machine state capturing component 120 if the register(s) value(s) were not saved (e.g., spilled) by the unmanaged component 110. In the example above, EBX needs to be restored but ESI and EDI do not need to be restored. The machine state restoring component 150 further publishes the fact that the unmanaged component 110 no longer desires to participate in garbage collection pointer enumeration. Significantly, it is possible for register(s) to be saved at many points in the unmanaged code. However the unmanaged code must restore all saved register(s) through any path through the unmanaged code. In particular it is possible that additional register(s) are saved between the time the machine state capturing component 120 was called and the time the machine date restoring component 150 was called. This scenario could lead to the machine state restoring component 150 updating a register that is presently in use by the unmanaged component 110 and will be restored to a value saved by the unmanaged component 110. Thus, any change made by the machine state restoring component 150 would be lost. Cleary this scenario must be prevented. This is the function of the `do-while` loop in the pseudo code above. This loop is never actually gets executed (e.g., the machine state restoring component 150 always returns 0); however, the unmanaged compiler can't determine this fact. Thus, the compiler is required to ensure that a code path that includes the loop saves and restores the same register(s) as a path that does not loop. For all reasonable compilers (that try to minimize instruction inside loops) this ensures that any spills that happen will happen outside the loop, and thus avoid the problematic scenario. It is to be appreciated that the Intel X86 machine instructions have been utilized for the purpose of illustration and not for limiting of the present invention. Those skilled in the art will recognize that the present invention is not limited to use with the X86 machine architecture but also can be employed with other machine architectures. FIG. 2 illustrates an exemplary memory heap 140 with garbage collection employed in accordance with as aspect of the present invention. FIG. 2 depicts the memory heap 140 at time t, t+1 and t+2. At time t, the memory heap 140 has areas of memory associated with three objects: object A 202, object B 204 and object C 206. At time t+1, the area of memory associated with object B 204 is no longer in use (e.g., program associated with object B has completed its use of this area of memory). At time t+2, garbage collection has been performed and the area of memory associated with object B 204 at time t has been reallocated. In view of the exemplary systems shown and described above, methodologies that may be implemented in accordance with the present invention will be better appreciated with reference to the flow charts of FIGS. 3, 4, 5 and 6. While, for purposes of simplicity of explanation, the methodologies are shown and described as a series of blocks, it is to be understood and appreciated that the present invention is not limited by the order of the blocks, as some blocks may, in accordance with the present invention, occur in different orders and/or concurrently with other blocks from that shown and described herein. Moreover, not all illustrated blocks may be required to implement a methodology in accordance with the present invention. The invention may be described in the general context of computer-executable instructions, such as program modules, executed by one or more components. Generally, program modules include routines, programs, objects, data structures, etc. that perform particular tasks or implement particular abstract data types. Typically the functionality of the program modules may be combined or distributed as desired in various embodiments. Turning to FIG. 3, a methodology 300 for capturing machine state in accordance with an aspect of the present invention is illustrated. At 310, unmanaged component saved register(s) and the stack pointer are stored in a machine state data structure. Next, at 320, the fact that the unmanaged component desires to participate in garbage collection is published (e.g., to the memory manager and/or garbage collection component). Next, at 330, a zero value is returned to the invoking routine. It is to be appreciated that a zero value has been utilized for the purpose of illustration and not for limiting of the present invention. Those skilled in the art will recognize that the present invention is not limited to this convention but also can be employed with other coordination schema between the invoking routine and the machine state capturing component. Next, referring to FIG. 4, a methodology 400 for unwinding information stored in a machine state data structure in accordance with an aspect of the present invention is illustrated. At 410, based at least in part upon information stored in a machine state data structure, native instruction(s) of an unmanaged component are simulated in order to facilitate garbage collection by determining location(s) and/or value(s) of machine register(s) saved by the unmanaged component. At 420, the register(s) value(s) are reported to a garbage collection component. Turning to FIG. 5, a methodology 500 for restoring machine state in accordance with an aspect of the present invention is illustrated. For each machine register, at 520, a determination is made whether the register was spilled by an unmanaged component. If the determination at 510 is YES, processing continues at 510 for any remaining machine registers. If the determination at 510 is NO, at 520, a value stored in a machine state data structure is loaded into the register. Thereafter, at 530, the fact that the unmanaged component no longer desires to participate in garbage collection is published (e.g., to the memory manager and/or garbage collection component). Next, at 540, a zero value is returned to the invoking routine. It is to be appreciated that a zero value has been utilized for the purpose of illustration and not for limiting of the present invention. Those skilled in the art will recognize that the present invention is not limited to this convention but also can be employed with other coordination schema between the invoking routine and the machine state restoring component. Next, referring to FIG. 6, a methodology 600 facilitating an unmanaged component to participate in garbage collection in accordance with an aspect of the present invention is illustrated. At 610, memory is allocated for a machine state data structure. Next, at 620, a machine state capturing component is invoked. At 630, a determination is made whether the machine state capturing component returned a zero value. If the determination at 630 is YES, a zero value is returned by the unmanaged component to the routine which invoked it. The YES branch of the decisional at 630 is generally not meant to be executed at run time; it is included to force an unmanaged compiler to provide machine instruction(s) related to information (e.g., register(s)) stored by the unmanaged component when it was invoked. If the determination at 630 is NO, at 640 the unmanaged component can perform work which can cause a garbage collection. Next at 650, a machine state restoring component is invoked. Next, at 660, a determination is made whether the machine state restoring component returned a zero value. If the determination at 660 is NO, processing continues at 620. The NO branch of the decision at 660 is generally not meant to be executed at run time; it is included to prevent an unmanaged compiler from spilling any additional unmanaged component saved register(s) between the invocation of the machine state capturing component and the machine state restoring component. If the determination at 660 is YES, no further processing occurs. In order to provide additional context for various aspects of the present invention, FIG. 7 and the following discussion are intended to provide a brief, general description of one possible suitable computing environment 1310 in which the various aspects of the present invention may be implemented. It is to be appreciated that the computing environment 1310 is but one possible computing environment and is not intended to limit the computing environments with which the present invention can be employed. While the invention has been described above in the general context of computer-executable instructions that may run on one or more computers, it is to be recognized that the invention also may be implemented in combination with other program modules and/or as a combination of hardware and software. Generally, program modules include routines, programs, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, one will appreciate that the inventive methods may be practiced with other computer system configurations, including single-processor or multiprocessor computer systems, minicomputers, mainframe computers, as well as personal computers, hand-held computing devices, microprocessor-based or programmable consumer electronics, and the like, each of which may be operatively coupled to one or more associated devices. The illustrated aspects of the invention may also be practiced in distributed computing environments where certain tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. FIG. 7 illustrates one possible hardware configuration to support the systems and methods described herein. It is to be appreciated that although a standalone architecture is illustrated, that any suitable computing environment can be employed in accordance with the present invention. For example, computing architectures including, but not limited to, stand alone, multiprocessor, distributed, client/server, minicomputer, mainframe, supercomputer, digital and analog can be employed in accordance with the present invention. With reference to FIG. 7, an exemplary environment 1310 for implementing various aspects of the invention includes a computer 1312, including a processing unit 1314, a system memory 1316, and a system bus 1318 that couples various system components including the system memory to the processing unit 1314. The processing unit 1314 may be any of various commercially available processors. Dual microprocessors and other multi-processor architectures also can be used as the processing unit 1314. The system bus 1318 may be any of several types of bus structure including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. The computer memory 1316 includes read only memory (ROM) 1320 and random access memory (RAM) 1322. A basic input/output system (BIOS), containing the basic routines that help to transfer information between elements within the computer 1312, such as during start-up, is stored in ROM 1320. The computer 1312 may further include a hard disk drive 1324, a magnetic disk drive 1326, e.g., to read from or write to a removable disk 1328, and an optical disk drive 1330, e.g., for reading a CD-ROM disk 1332 or to read from or write to other optical media. The hard disk drive 1324, magnetic disk drive 1326, and optical disk drive 1330 are connected to the system bus 1318 by a hard disk drive interface 1334, a magnetic disk drive interface 1336, and an optical drive interface 1338, respectively. The computer 1312 typically includes at least some form of computer readable media. Computer readable media can be any available media that can be accessed by the computer 1312. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer 1312. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media. A number of program modules may be stored in the drives and RAM 1322, including an operating system 1340, one or more application programs 1342, other program modules 1344, and program non-interrupt data 1346. The operating system 1340 in the computer 1312 can be any of a number of commercially available operating systems. A user may enter commands and information into the computer 1312 through a keyboard 1348 and a pointing device, such as a mouse 1350. Other input devices (not shown) may include a microphone, an IR remote control, a joystick, a game pad, a satellite dish, a scanner, or the like. These and other input devices are often connected to the processing unit 1314 through a serial port interface 1352 that is coupled to the system bus 1318, but may be connected by other interfaces, such as a parallel port, a game port, a universal serial bus ("USB"), an IR interface, etc. A monitor 1354, or other type of display device, is also connected to the system bus 1318 via an interface, such as a video adapter 1356. In addition to the monitor, a computer typically includes other peripheral output devices (not shown), such as speakers, printers etc. The computer 1312 may operate in a networked environment using logical and/or physical connections to one or more remote computers, such as a remote computer(s) 1358. The remote computer(s) 1358 may be a workstation, a server computer, a router, a personal computer, microprocessor based entertainment appliance, a peer device or other common network node, and typically includes many or all of the elements described relative to the computer 1312, although, for purposes of brevity, only a memory storage device 1360 is illustrated. The logical connections depicted include a local area network (LAN) 1362 and a wide area network (WAN) 1364. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet. When used in a LAN networking environment, the computer 1312 is connected to the local network 1362 through a network interface or adapter 1366. When used in a WAN networking environment, the computer 1312 typically includes a modem 1368, or is connected to a communications server on the LAN, or has other means for establishing communications over the WAN 1364, such as the Internet. The modem 1368, which may be internal or external, is connected to the system bus 1318 via the serial port interface 1352. In a networked environment, program modules depicted relative to the computer 1312, or portions thereof, may be stored in the remote memory storage device 1360. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used. The present invention has been described with respect to facilitating garbage collection. However, those skilled in the art will recognize that the system and methods of the present invention can be utilized to facilitate exception handling and/or program debugging. What has been described above includes examples of the present invention. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the present invention, but one of ordinary skill in the art may recognize that many further combinations and permutations of the present invention are possible. Accordingly, the present invention is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term "includes" is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term "comprising" as "comprising" is interpreted when employed as a transitional word in a claim.
|
Same subclass Same class Consider this |
||||||||||