Relation-based ordering of objects in an object heap

[0002] The invention is generally related to computers and computer software. More specifically, the invention is generally related to the management of objects in an object heap.

[0003] Managing available memory is critically important to the performance and reliability of a data processing system such as a computer. Specifically, data used by a computer program is typically stored in a computer within a memory that has a limited address space. In many computers, data is stored in the form of “objects” that are allocated space in a portion of the memory referred to as an “object heap”. Objects also often include “references” (also known as pointers) to other objects so that a computer program can access information in one object by following a reference from another object. Typically each computer program has its own object heap, so if multiple computer programs are active in a computer, multiple object heaps may be maintained in the computer.

[0004] Whenever new data is to be used by a computer program, a portion of the free memory is reserved for that data using a process known as “allocating” memory. Given that the amount of memory available in a computer is limited, it is important to free up, or “deallocate”, the memory reserved for data that is no longer being used by the computer. Otherwise, as available memory is used up, the performance of the computer typically decreases, or a system failure may occur.

[0005] A computer program known as a garbage collector is often used to free up unused memory that has been allocated by other computer programs in a computer. Often, a garbage collector executes concurrently with other computer programs to periodically scan through the object heap(s) and deallocate any memory that is allocated to unused objects (a process also known as “collecting” objects). Different computer programs that operate concurrently in a computer often include one or more “threads” that execute concurrently with one another. Moreover, when different computer programs use different object heaps, separate garbage collector computer programs, also referred to as collector threads, may be used to manage each object heap.

[0006] One specific type of garbage collector is a copying garbage collector, which manages an object heap by partitioning the object heap into “from-space” and “to-space” partitions, and copying valid and currently-used objects from the from-space to the to-space, in effect leaving unused objects behind. A specific implementation of a copying garbage collector is a generational garbage collector, which partitions an object heap into new and old partitions. A generational garbage collector relies on the tendency for newer objects to “die”, or cease to be used, more frequently than older objects. Put another way, as an object is used over time, it becomes less and less likely that the object will cease being used.

[0007] A generational garbage collector manages an object heap by repeatedly scanning through newer objects in the new partition of the object heap, discarding and deallocating the memory for objects that are no longer in use, and moving objects that live beyond a threshold period of time into the old partition of the object heap. Given that older objects tend to be more stable, typically no scanning of the old partition of the object heap is required.

[0008] A generational garbage collector typically stores objects in the old partition of the object heap in a linear fashion—that is, one after another as each object is found to meet the criteria for being moved into the old partition. Likewise, objects in the new partition of the object heap are typically widely scattered throughout the new partition due to the deallocation and movement of objects by the garbage collector and the addition of new objects to then-available locations in the partitions.

[0009] As with generational garbage collectors, other copying garbage collector implementations also copy objects from a from-space to a to-space in a linear fashion. With the allocation and initial placement of objects in the from-space occurring by a process other than the garbage collector, however, objects tend to become widely scattered throughout the from-space with these copying garbage collector implementations as well.

[0010] An inherent result of the conventional manners of storing objects in an object heap is that the various objects used by a computer program can become widely dispersed throughout an object heap over time. Having a relatively wide dispersion of objects in an object heap, however, can result in sub-optimal performance for a computer due to memory swapping concerns.

[0011] Specifically, most computers rely on a multi-level memory architecture to balance memory performance with cost. Most computers include one or more levels of small capacity and high speed cache memory interfaced with a larger capacity but relatively slower main memory. As data is needed by a computer program, the data is copied from the main memory to a cache memory for access by a processor in the computer. Data is typically organized into blocks, or “cache lines”, with all of the data allocated to a particular cache line swapped into and out of a cache as a group.

[0012] Some computers also implement a virtual memory scheme where the addressable memory space is larger than the physical storage available for the main memory. Similar to caching, in a virtual memory scheme data is organized into pages, and data is swapped page-by-page between main memory and an external storage device such as a direct access storage device (DASD).

[0013] The primary benefit of a multi-level memory architecture is that more frequently-used data can often be maintained in higher levels of memory so that the data can be accessed more quickly. Whenever data to be accessed from a cache memory is allocated to a cache line that is not currently stored in the cache memory, a cache miss occurs, and retrieval of the data takes longer since the data must be retrieved from a lower level of memory. Similarly, whenever data to be accessed from the main memory is allocated to a page that is not currently stored in the main memory, a page fault occurs, and retrieval of the data takes still longer since the data must be swapped in from external storage.

[0014] An object heap typically occupies multiple cache lines, and in many instances, multiple pages. Consequently, with a relatively wide dispersion of objects in an object heap, successive accesses to objects located in different locations in the object heap may require a substantial amount of memory swapping within each cache memory, and possibly within the main memory as well. As a result, accesses to the object heap tend to take longer, and the computer operates at less than peak efficiency.

[0015] Therefore, a substantial need exists in the art for a manner of improving the performance of a computer in accessing an object heap, particularly through improved garbage collection techniques.

[0016] The invention addresses these and other problems associated with the prior art by providing an apparatus, program product, and method that organize data objects in an object heap based upon access relationships between the data objects. By doing so, data objects that are accessed in close succession with one another are more likely to be located within the same page, and possibly within the same cache line, as one another. Consequently, when accessing such objects, the frequency of memory swapping within a multi-level memory architecture (e.g., within a particular cache memory, or within a virtual memory scheme, as appropriate for the particular architecture) is often reduced, resulting in an overall improvement in system performance.

[0017] An access relationship between two or more data objects may be based at least in part upon a likely temporal proximity of the accesses to such data objects, e.g., when a group of objects are typically accessed one after another during execution of a computer program. An access relationship between multiple data objects may also be based at least in part on the relative frequencies of access of different data objects. Other manners of defining an access relationship will become apparent to one of ordinary skill in the art upon reading the disclosure presented herein.

[0018] In one specific embodiment of the invention, the ordering of data objects in an object heap relies on profiled access information generated for different classes of data objects used by a computer program. The profiling may be performed at various times, including during compilation, loading, or execution of a computer program. Typically, information such as the number of accesses to data objects and/or the order in which data objects are accessed may be predicted and utilized in determining how to order data objects within an object heap.

[0019] These and other advantages and features, which characterize the invention, are set forth in the claims annexed hereto and forming a further part hereof. However, for a better understanding of the invention, and of the advantages and objectives attained through its use, reference should be made to the Drawings, and to the accompanying descriptive matter, in which there is described exemplary embodiments of the invention.

[0020] FIG. 1 is a block diagram of a networked computer system consistent with the invention.

[0021] FIG. 2 is a block diagram of an exemplary hardware and software environment for a computer from the networked computer system of FIG. 1.

[0022] FIG. 3 is a block diagram of the software components in the environment of FIG. 2.

[0023] FIGS. 4A and 4B are flowcharts illustrating the program flow of the object access profiling routine of FIG. 3.

[0024] FIG. 5 is a block diagram of an exemplary load/store count table generated by the object access profiling routine of FIGS. 4A and 4B.

[0025] FIG. 6 is a block diagram of an exemplary access tree generated by the object access profiling routine of FIGS. 4A and 4B.

[0026] FIG. 7 is a block diagram of an exemplary Java class file.

[0027] FIG. 8 is a flowchart illustrating the program flow of a collector thread executed by the garbage collection logic of FIG. 3.

[0028] FIGS. 9A and 9B are flowcharts illustrating the program flow of the copy roots routine referenced in FIG. 8.

[0029] FIG. 10 is a flowchart illustrating the program flow of the swap partitions routine referenced in FIG. 8.

[0030] FIG. 11 is a flowchart illustrating an exemplary call stack occurring during execution of the collector thread of FIG. 8.

[0031] FIGS. 12A-12C are block diagrams of an exemplary object heap operated upon by the collector thread of FIG. 8.

[0032] Turning to the Drawings, wherein like numbers denote like parts throughout the several views, FIG. 1 illustrates a computer system 10 consistent with the invention. Computer system 10 is illustrated as a networked computer system including one or more client computers 12, 14 and 20 (e.g., desktop or PC-based computers, workstations, etc.) coupled to server 16 (e.g., a PC-based server, a minicomputer, a midrange computer, a mainframe computer, etc.) through a network 18. Network 18 may represent practically any type of networked interconnection, including but not limited to local-area, wide-area, wireless, and public networks (e.g., the Internet). Moreover, any number of computers and other devices may be networked through network 18, e.g., multiple servers.

[0033] Client computer 20, which may be similar to computers 12, 14, may include a central processing unit (CPU) 21; a number of peripheral components such as a computer display 22; a storage device 23; a printer 24; and various input devices (e.g., a mouse 26 and keyboard 27), among others. Server computer 16 may be similarly configured, albeit typically with greater processing performance and storage capacity, as is well known in the art.

[0034] FIG. 2 illustrates in another way an exemplary hardware and software environment for an apparatus 30 consistent with the invention. For the purposes of the invention, apparatus 30 may represent practically any type of computer, computer system or other programmable electronic device, including a client computer (e.g., similar to computers 12, 14 and 20 of FIG. 1), a server computer (e.g., similar to server 16 of FIG. 1), a portable computer, an embedded controller, etc. Apparatus 30 may be coupled in a network as shown in FIG. 1, or may be a stand-alone device in the alternative. Apparatus 30 will hereinafter also be referred to as a “computer”, although it should be appreciated the term “apparatus” may also include other suitable programmable electronic devices consistent with the invention.

[0035] Computer 30 typically includes at least one processor 31 coupled to a memory 32. Processor 31 may represent one or more processors (e.g., microprocessors), and memory 32 may be implemented using any of a number of known multi-level memory architectures, e.g., including a main storage 32aimplemented using random access memory (RAM) devices, and one or more supplemental levels of memory, e.g., one or more levels of cache memory 32b(whether external or internal to processor 31), as well as various non-volatile or backup memories (e.g., programmable or flash memories), read-only memories, etc. As is known in the art, data is swapped between main storage and cache memory, and/or between different levels of cache memory, in the form of “cache lines”, with any access to data that is non-resident in a particular level of cache resulting in a “cache miss” and additional delay associated with retrieving the required data from another level of memory.

[0036] In addition, memory 32 may be considered to include memory storage physically located elsewhere in computer 30, e.g., (as discussed above) any cache memory or registers in processor 31, as well as any storage capacity used as a virtual memory, e.g., as stored on a mass storage device 36 or on another computer coupled to computer 30 via network 38. As is known in the art, with a virtual memory architecture, data is swapped between mass storage and main storage in the form of “pages”, with any access to data that is non-resident in the main storage resulting in a “page fault” and additional delay associated with retrieving the required data from external storage.

[0037] Computer 30 also typically receives a number of inputs and outputs for communicating information externally. For interface with a user or operator, computer 30 typically includes one or more user input devices 33 (e.g., a keyboard, a mouse, a trackball, a joystick, a touchpad, and/or a microphone, among others) and a display 34 (e.g., a CRT monitor, an LCD display panel, and/or a speaker, among others). It should be appreciated, however, that with some implementations of computer 30, e.g., some server implementations, direct user input and output may not be supported by the computer.

[0038] For additional storage, computer 30 may also include one or more mass storage devices 36, e.g., a floppy or other removable disk drive, a hard disk drive, a direct access storage device (DASD), an optical drive (e.g., a CD drive, a DVD drive, etc.), and/or a tape drive, among others. Furthermore, computer 30 may include an interface with one or more networks 38 (e.g., a LAN, a WAN, a wireless network, and/or the Internet, among others) to permit the communication of information with other computers coupled to the network. It should be appreciated that computer 30 typically includes suitable analog and/or digital interfaces between processor 31 and each of components 32, 33, 34, 36 and 38 as is well known in the art.

[0039] Computer 30 operates under the control of an operating system 40, and executes or otherwise relies upon various computer software applications, components, programs, objects, modules, data structures, etc. (e.g., compiler 42, virtual machine 44, source code 46 and class files 48, among others). Moreover, various applications, components, programs, objects, modules, etc. may also execute on one or more processors in another computer coupled to computer 30 via a network 38, e.g., in a distributed or client-server computing environment, whereby the processing required to implement the functions of a computer program may be allocated to multiple computers over a network.

[0040] In general, the routines executed to implement the embodiments of the invention, whether implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions will be referred to herein as “computer programs”, or simply “programs”. The computer programs typically comprise one or more instructions that are resident at various times in various memory and storage devices in a computer, and that, when read and executed by one or more processors in a computer, cause that computer to perform the steps necessary to execute steps or elements embodying the various aspects of the invention. Moreover, while the invention has and hereinafter will be described in the context of fully functioning computers and computer systems, those skilled in the art will appreciate that the various embodiments of the invention are capable of being distributed as a program product in a variety of forms, and that the invention applies equally regardless of the particular type of signal bearing media used to actually carry out the distribution. Examples of signal bearing media include but are not limited to recordable type media such as volatile and non-volatile memory devices, floppy and other removable disks, hard disk drives, optical disks (e.g., CD-ROM's, DVD's, etc.), among others, and transmission type media such as digital and analog communication links.

[0041] In addition, various programs described hereinafter may be identified based upon the application for which they are implemented in a specific embodiment of the invention. However, it should be appreciated that any particular program nomenclature that follows is used merely for convenience, and thus the invention should not be limited to use solely in any specific application identified and/or implied by such nomenclature.

[0042] Those skilled in the art will recognize that the exemplary environments illustrated in FIGS. 1 and 2 are not intended to limit the present invention. Indeed, those skilled in the art will recognize that other alternative hardware and/or software environments may be used without departing from the scope of the invention.

[0043] The embodiments described herein generally operate by organizing data objects in an object heap based upon access relationships between the data objects. An object heap can include any segment of a computer memory that represents the working memory for a computer program, typically any segment of memory in which data is dynamically allocated, used and managed during execution of a computer program. Typically, but not necessarily, an object heap is managed by a garbage collector, which may run concurrently with a computer program, or which may operate as a “stop-the-world” collector that halts execution of a computer program, or simply a specific thread of the program, whenever garbage collection is performed. Various types of garbage collectors, which are generally known in the art, may be used consistent with the invention.

[0044] An access relationship as described herein typically exists between two or more data objects based at least in part upon a likely temporal proximity of the accesses to such data objects and/or based at least in part on the relative frequencies of access of different data objects. For example, an access relationship may be defined whenever a parent-child relationship exists between two objects, i.e., whenever one object (the parent) accesses some portion of the other object's (the child's) memory. Children in turn may also , have their own relationships where they are the parent—even of other objects that are themselves parents of those children. By organizing objects in the manner described herein, cache misses and/or page faults in a multi-level memory architecture are reduced, as the likelihood is increased that objects that are accessed within a short time frame will be within the same organizational block in memory (e.g., a cache line or virtual memory page, as appropriate).

[0045] In certain embodiments discussed hereinafter, multiple data objects that fall within the same access chains—that is, objects that are referenced in various sequences after a particular root object is accessed—can logically be grouped together in memory (e.g., within a continuous memory segment in an object heap) based upon the temporal proximity between the objects in such a group. Moreover, in certain embodiments, the specific objects within such a group may be arranged relative to one another based upon relative access frequencies and/or the order in which the objects are accessed.

[0046] The specific embodiment described hereinafter focus on a particular application of the invention in optimizing the performance of computer programs executed in the Java programming environment developed by Sun Microsystems. However, it should be appreciated that the invention may have applicability in other object-oriented programming environments that utilize an object heap. Moreover, given that all data (even when not referred to as an “object” in an object-oriented sense) can be represented as an object, the invention may also have applicability in non-object-oriented programming environments as well. Thus, the invention is not limited to the specific Java-based implementation described hereinafter.

[0047] FIG. 3 illustrates the primary software components utilized in the illustrated embodiment to implement relation-based object ordering consistent with the invention. Specifically, FIG. 3 shows a compiler 42 coupled to a virtual machine 44, with the compiler receiving as input source code 46 and outputting in response thereto one or more class files 48 capable of being executed by virtual machine 44.

[0048] Each of components 42-48 is configured to be compatible with the various known Java language specifications. Source code 46 is a human-readable Java source code representation of a computer program. Compiler 42 is utilized to generate from the Java source code 46 a plurality of bytecodes that represent an intermediate representation of a Java computer program, as illustrated at block 50.

[0049] The generated bytecodes are organized into one or more classes, representing the templates for the objects that are to be allocated and utilized during execution of the computer program by virtual machine 44. The classes are organized into class files containing both the executable bytecodes and data relied upon by such executable code. Other information about an object is also typically included within the class file, as is known in the art.

[0050] Once generated, the classes are processed by a class verification block 51, which performs various verification and analysis operations on the classes to ensure that the classes are error free and will not cause various run-time errors, as well as that all security requirements of the Java language are met. It should be appreciated that both bytecode generation and class verification are well known, and thus need not be discussed in any further detail herein.

[0051] Once verified, the classes are passed to an object access profiling block 52 to perform access profiling in a manner consistent with the invention. Specifically, access patterns for the classes are generated based upon simulation of the executable code defined within the classes (discussed in greater detail below with respect to FIGS. 4A and 4B). The output of block 52 is one or more class files 48. As discussed in greater detail below, such class files may include profiled access information embedded therein, although in some embodiments, such information may not be stored in the class files, whereby object access profiling in block 52 would not be performed.

[0052] Once generated, class files may be distributed to third parties and/or stored to some persistent medium for later execution, or may be immediately executed by virtual machine 44. Virtual machine 44 implements a Java Virtual Machine (JVM), which essentially emulates the operation of a hypothetical microprocessor on a specific computer platform. Different virtual machines may be utilized to permit the class files to be executed on different platforms. Moreover, it should be appreciated that compiler 42 and virtual machine need not reside on the same computer system.

[0053] Class files are loaded by virtual machine 44 using a class loader component 54, in a manner generally known in the art. Component 54 in the illustrated embodiment, however, is also capable of passing the loaded class files to an object access profiling block 56 to obtain profiled access information about the class files if no such information was embedded in the class files by the compiler. In addition, class loader 54 may also perform additional class verification to verify that Java security rules are met, in a manner also known in the art.

[0054] To provide working storage during execution of the computer program, virtual machine 44 includes an object heap 58 including a “From” partition 60 and a “To” partition 62. Data storage is allocated during runtime in From partition 60 for use as working storage. Then, a garbage collector (represented by garbage collection logic 70) periodically copies reachable objects from partition 60 to To partition 62 and swaps the From and To partitions so that the previous To partition becomes the new From partition, and vice versa. Such an object heap management algorithm is known as copying-type garbage collection. However, as other object heap management algorithms may be used, other object heap organizations may be utilized as well.

[0055] In response to the loading of classes by class loader 54, one or more threads 64 are executed by an interpreter 63 that generates for each bytecode suitable native code appropriate for the platform upon which the virtual machine executes. Each thread has allocated therefor a call stack 66 upon which data necessary for maintaining coherence through different method calls is maintained. In addition, as shown at 68, additional object access profiling may be performed during run time, if necessary. The object heap is managed by garbage collection logic 70, which in the illustrated implementation is a copying-type garbage collector.

[0056] As shown in FIG. 3, each thread shares an object heap managed by a single garbage collector thread. Multiple computer programs executing simultaneously on the same computer system may also share the same object heap. In the illustrated embodiment, however, additional computer programs are allocated separate object heaps (and associated garbage collectors), but are not shown in the figure.

[0057] It will be appreciated that the interpretation and execution of Java bytecodes by virtual machine 44 are operations that are well known in the art. Additional modifications to the virtual machine, including just-in-time compilation, among other alternatives, may also be implemented in virtual machine 44.

[0058] As discussed above, object access profiling consistent with the invention may be performed at various times in the life of a computer program, e.g., during compilation (represented at block 52), during loading (as illustrated by block 56), and/or during execution (as illustrated at block 68). It should be appreciated that typically profiling will be performed at only one such time period, although it may be necessary to check to see that object access profiling has been performed and that suitable access information has been generated, e.g., during class loading if it is anticipated that the virtual machine may execute class files that have been generated by other systems not having access to object access profiling during compilation. Generally, it is preferable to perform profiling as early in the process as possible, e.g., during compilation, or during loading, to minimize any performance penalties during execution of a computer program.

[0059] One suitable routine for performing object access profiling consistent with the invention is illustrated at 100 in FIGS. 4A and 4B. As shown in FIG. 4A, routine 100 begins in block 102 by retrieving the class, if necessary. As discussed above, object access profiling may be performed after a class has already been loaded and/or during execution of the program code stored in the class file. In such instances retrieval of the class may not be necessary.

[0060] Next, in block 104, a load/store count table and an access order tree data structure are initialized. The load/store count table is utilized to maintain counts of the predicted accesses to each object referenced in a class, separated by load accesses and store accesses. For example, as shown in FIG. 5, one suitable data structure for the load/store count table is illustrated at 75, including a plurality of entries 76, each including an object ID field 78, a load count field 80, and a store count field 82. Object ID field 78 includes any unique identifier from which a referenced object can be identified. Load count field 80 stores the number of load-type accesses (e.g., aload and get field operations in Java), and store count field 82 likewise stores a number of store-type accesses (e.g., astore and put field operations in Java), based upon profiling information. Typically, the table 75 is initialized with the data in all entries cleared.

[0061] It should be appreciated that other data structures may be utilized to represent the number of load and store accesses for a given class, including linked lists and hash tables, among others. Moreover, it should be appreciated that in some embodiments it ay not be necessary to maintain separate counts for load and store accesses, whereby the load and store count fields 80, 82 can be combined into the same field. Moreover, as will be discussed in greater detail below, the access information for certain objects may be maintained within the access order tree data structure, whereby table 75, or any equivalent data structure, would not be required.

[0062] FIG. 6 illustrates one exemplary access order tree data structure 85, including a root node or object 86 from which a plurality of nodes 88 depend therefrom. Root node 86 represent the starting point for the tree under which all objects referenced by a particular method. Nodes 88 generally represent the fields, or referenced objects, within a particular method that is represented by root 86. Note that some of nodes 88 can be referenced by other nodes 88, representing a chain of referenced objects. For example, for the “this” object of the exemplary class represented in tree 85, a call or access chain from the “this” object to a “table” object, a “tempObject” object and then a “next” object is illustrated, which represents that, during execution of an object defined by the exemplary class, objects “table”, “tempObject” and “next” are referenced in order immediately subsequent to a reference to the “this” object.

[0063] Within each node may be stored simply the object identifier for the object in the call chain. In other embodiments, it may also be desirable to include within each node an access count representing the number of accesses to that object. Such access counts may be segregated by load and stores, or may be grouped together. As discussed above, this information may be stored in the nodes as an alternative to using a separate access table.

[0064] Moreover, each tree is typically segregated by the objects referenced by each method defined for that class. It may be desirable in such instances, for example, to insert an additional node between root node 86 and each field node 88 such that the field nodes may be classified by method. It should also be appreciated that various data structures, e.g., linked lists and the like, may be used to represent a call tree consistent with the invention. Typically, initialization of an access order tree includes initializing a root node object, having no children nodes associated therewith.

[0065] Returning now to FIG. 4A, once the load/store count table and access order tree have been initialized, control passes to block 106 to enter a loop within which each bytecode in the class is analyzed to build the load/store count table. Specifically, for each bytecode in the class, control passes to block 108 to determine whether the bytecode operates on a new object—that is, whether the bytecode references an object that does not have a corresponding entry in the load/store count table. If so, control passes to block 110 to add a new entry in the load/store count table for the new object, including storing the object identifier in the new entry and initializing the load and store counts to zero. Control then passes to block 112 to determine whether the bytecode performs a load access on the object. Also, returning to block 108, if the bytecode does not operate on a new object, control passes directly to block 112, bypassing block 110.

[0066] If the bytecode does perform a load-type access on the object, control passes to block 114 to increment the load count for that object—that is, the value stored in the load count field of the entry corresponding to the object is advanced by one. Control then returns to block 106 to process additional bytecodes.

[0067] Returning to block 112, if the bytecode does not perform a load access on the object, control passes to block 116 to determine whether the bytecode performs a store-type access on the object. If not, no further processing of the bytecode need occur, and control returns to block 106. If, however, the bytecode does perform a store access on the object, control passes to block 118 to increment the store count for that object, prior to returning control to block 106.

[0068] Once all bytecodes in the class have been processed, block 106 passes control to block 120, shown in FIG. 4B. Block 120 initiates a second loop in which each bytecode in the class is processed to build the access order tree for the class.

[0069] For each bytecode, control passes to block 122 to examine the bytecode using a simulation stack. Specifically, the effects the execution of the bytecode are simulated to build a “simulated” call stack.

[0070] Once the bytecode is examined with the simulation stack, control passes to block 124 to determine whether the bytecode is a load or store operation that uses an object reference from which to load or store—that is, whether the bytecode accesses another object, referred to herein as a “referenced object” to perform a load or store operation. If not, control returns to block 120 to process additional bytecodes.

[0071] If, however, the bytecode is a load or store operation that uses an object reference, control passes to block 126 to determine whether a previous object exists that loaded or stored this referenced object. The previous object as used herein represents an object that was previously accessed to reach the access to the referenced object in question. As such, a call or access chain is defined between the previous object (if such exists) and the referenced object.

[0072] First, assuming that no previous object yet exists for the referenced object, control passes to block 128 to determine whether the referenced object is already in the access order tree. If not, a new node is added to the tree for the referenced object, and control passes to block 132 to increment an access count for the referenced object. Returning to block 128, if the object is already in the tree, no new node is added, and control passes directly to block 132 to increment the access count therefor.

[0073] As discussed above, the access count may be maintained within each node of the tree. In the alternative, the access count information may be maintained in the load/store count table, whereby block 132 would not be required.

[0074] After the access count is incremented for the referenced object, control passes to block 134 to determine whether the bytecode is a load operation. If not, control returns to block 120 to process additional bytecodes. If, however, the bytecode is a load operation, control passes first to block 136 to set the previous object to the referenced object, essentially traversing down the tree one level to set the referenced object as the previous object for any subsequent load or store operations. Control then returns to block 120 to process additional bytecodes.

[0075] Now returning to block 126, if a previous object exists for the load or store operation, control passes to block 138 to determine whether the referenced object exists in the list of children for the previous object. If so, control passes directly to block 132 to increment the access count for the referenced object. If, however, the referenced object does not exist in the list of children, control first passes to block 140 to add a node for the referenced object to the previous object's list of children, indicating that the referenced object has an access relationship with the previous object by virtue of its being accessed immediately subsequent to an access to the previous object.

[0076] Once all bytecodes have been processed for the class, an access order tree data structure is constructed for the class, from which it can be ascertained what objects are accessed in what order in the class. Control then passes from block 120 to block 142 to order each node's children based upon the access counts therefor. Specifically, for each node, the children therefor are ordered in the access tree based upon the access counts stored in each of those nodes, with the child having the highest access count placed first, and with other children following in descending order of access count. This secondary level of ordering therefore organizes child nodes that are accessed more frequently closer to the parent node to ensure that the more frequently-traversed call or access chains are stored as close as possible to one another.

[0077] Once each node's children are organized in the manner described above, control passes to blocks 144 and 146 to optionally store the recently-generated profiled access information in the class file for later use during run time. It should be appreciated, however, that if object access profiling is being performed at run-time, it may not be necessary to order the objects in the class file or store the access information within the class file. As such, in these circumstances, blocks 144 and 146 may be omitted.

[0078] In block 144, the object references in the class file are ordered according to the access order tree, therefore utilizing the access information that is inherent in the tree, whereby the references to objects that are accessed in particular chains or sequences (i.e., with temporal proximity) are ordered close to one another to form groups, with the references to objects within such groups (e.g., sibling objects depending from the same parent object) further ordered by relative access frequency. It should be appreciated that this type of ordering may be performed simply by traversing through the tree through an algorithm that recursively selects the next node to be stored in the class as the left-most unprocessed child for a currently-processed node, then backing up to a parent node when all child nodes have been processed.

[0079] Consequently, using the above-described algorithm, the class file itself is organized in such a manner that references to related objects are located closer to one another. As a result, subsequent loading of a class file optimized in this manner into the object heap during runtime also has the capability to reduce cache misses and/or page faults within the From partition of the object heap, independent of any gains associated with improved garbage collection.

[0080] Once the object references in the class have been ordered in block 144, control passes to block 146 to store the load/store count table and access order tree in the class file. Profiling is then complete, and routine 100 terminates.

[0081] FIG. 7 is a diagram of an exemplary Java class file 150 output by compiler 42 of FIG. 3, and including the profiled access information generated by routine 100 of FIGS. 4A and 4B. Class file 150 is the standard external representation of a Java class that enables the “portability” of Java—its ability to run on any system with a conforming Java virtual machine (JVM), regardless of the underlying architecture of the platform supporting the JVM. Class file 150 includes a number of data fields 152-173. “Magic” data field 152 is a particular arbitrary bit sequence that allows the file to be identified as a Java class file. The bit sequence must have the hexadecimal value 0×CAFEBABE to allow the file to be recognized as a Java class file. Also, “minor version” and “major version” data fields 154 and 156 identify the version of the class file.

[0082] “Constant pool” data field 159 defines a list of entries of varying lengths, with the size of the constant pool identified by “constant pool count” data field 158. Each entry represents a constant or external reference used elsewhere in the class file. The use of the constant pool allows a single occurrence of a value to serve multiple needs within the class file.

[0083] “Access flags” data field 160 defines some of the basic characteristics of the class represented by the class file, including the authority required to reference the class from other classes. “This class” data field 162 is an index into the constant pool of the entry that contains the name of this class, and “superclass” data field 164 is an index into the constant pool of the entry that contains the name of the superclass of this class.

[0084] “Interfaces” data field 167 defines a list of constant pool index values that identify the names of interfaces which this class implements, with the size thereof identified by “interfaces count” data field 166. Interfaces are used in Java to achieve some of the same functions that “multiple inheritance” provides in other object-oriented languages.

[0085] “Fields” data field 169 defines a list of entries of varying length which describe the fields of this class, with the size thereof identified by “fields count” data field 168. The names of the fields and, where present, their initialization values are represented as indexes into the constant pool.

[0086] “Methods” data field 171 defines a list of entries of varying length which describe the methods of this class, with the size thereof identified by “methods count” data field 170. The names of the fields are represented as indexes into the constant pool. The actual interpretable code (i.e., the set of bytecodes) for each method is appended to the end of its method entry.

[0087] “Attributes” data field 173 defines a repository for other characteristics of the class, with the size thereof identified by “attributes count” data field 172.

[0088] The references to the objects referenced by the class are stored in fields data field 169, and it is within this data field that the references are organized in the manner described above with respect to block 144 of FIG. 4B. The profiled access information for the class is typically stored within the attributes field 173 of the class file, as represented by the placement of table 75 and access order tree 85 in FIG. 7.

[0089] FIG. 8 illustrates a collector thread 200 executed by the garbage collection logic 70 (FIG. 3). Generally, the collector thread is initialized in block 202, which typically includes the allocation of the object heap in memory. Next, in block 204, the collector thread waits for a triggering event, e.g., expiration of a timer, a reduction in the available memory below a predetermined threshold, etc., as is well known in the garbage collection art.

[0090] Once the triggering event occurs, the collection cycle is initialized in block 206. Next, a copy roots routine 208 is executed to copy all reachable objects from the From partition of the object heap into the To partition thereof. Next, a swap partitions routine 210 is executed to swap the To and From partitions so that the objects copied to the To partition are in essence “returned” to the From partition. As a result, any objects not copied into the To partition in routine 208 will effectively be discarded on the next garbage collection cycle as new objects are copied into the previous From partition.

[0091] FIGS. 9A and 9B next illustrate the operation of copy roots routine 208 in implementing relation-based object ordering in a manner consistent with the invention. As shown in FIG. 9A, routine 208 begins in block 212 by initiating a loop to ensure that profiled accessed information is available for each class in the computer program utilizing the object heap. For each such class, control passes from block 212 to block 214 to determine whether the class file includes the profiled access information generated above in routine 100. If so, no further processing of the class need occur, and control returns to block 212 to process additional classes.

[0092] If, however, no such access information is available, object access profiling routine 100 is called for that class, and subsequently block 216 reorders the class object reference fields based upon relative access frequency. Control then returns to block 212 to process additional classes.

[0093] Once all classes have been processed, profiled access information for each class is available to the garbage collector. Control then passes to block 218 to initiate a loop to process the object references currently disposed on the call stack. As discussed above, the call stack typically includes references to objects that are utilized during the execution of more or more methods in a computer program. Whenever a method is called by a computer program, the parameters to be used by that method are passed to that method by pushing an entry onto the call stack including such parameters. In addition, return information about the calling method is added to the entry so that the program can resume once the called method is terminated. Whenever a called method terminates or completes, the entry therefor is popped from the call stack, and the information returned to the calling method. The use and operation of a call stack is well known in the art.

[0094] Block 218 specifically initiates a FOR loop to sort each object reference currently on the call stack into one of two lists, an “order” list containing all objects that are found in call or access chains, and an “orphaned” lists for all other objects. Thus, for each such reference, control passes to block 220 to determine whether the referenced object for that object reference is in the access order tree for that class. If so, control passes to block 222 to add the referenced object to the “order” list. If not, the referenced object is added to the “orphaned” list in block 224. Once all objects have been processed in this manner, block 218 passes control to block 226 and 228 to separately handle the objects in each list.

[0095] Block 226 handles the objects in the “order” list, essentially copying the objects referenced by each object in the “order” list into the To partition in the access order defined by the access order tree. In addition, at this time, a forwarding pointer is added to each original object in the From partition, which points to the new copy of that object in the To partition. Consequently, any references to the old copy of the object in the From partition are able to locate the new copy of the object simply by following the forwarding pointer therefor.

[0096] For the objects in the “orphaned” list, block 228 copies each object to the To partition, also adding a forwarding pointer to the original copy of the object in the From partition. Since the objects in the “orphaned” list are not present on the access order tree, no particular organization of such objects is used.

[0097] Upon completion of blocks 226 and 228, processing of the object references on the call stack is complete, and control passes to block 230 of FIG. 9B to initiate a loop for processing all static objects in the object heap. As is known in the art, a static object is typically an object that is globally accessible.

[0098] Block 230 initiates a loop to process each static object. For each such object, control passes to block 232 to process each reference in that static object. For each such reference, control passes to block 234 to determine whether the object referenced by that reference has already been copied to the To partition. If so, control returns to block 232 to process additional references in the static object. If, however, the referenced object is not in the To partition, control passes to block 236 to copy the referenced object to the To partition, and to add a forwarding pointer to the original copy in the From partition that points to the new copy in the To partition. Control then returns to block 232 to process additional references.

[0099] Once every reference in the current static object has been processed block 232 returns control to block 230 to process additional static objects in the manner described above. Then, once all static objects have been processed, block 230 then passes control to block 238 to ensure all objects that are referenced by reachable objects in the To partition are also copied over to the To partition.

[0100] Specifically, block 238 processes each object in the To partition by passing control to block 240 to process each reference in the object. For each such reference, control passes to 242 to determine whether the referenced object is in the From partition. If it is not, control returns to block 240 to process additional references in the currently-processed object. However, if the referenced object is still in the From partition, control passes to block 244 to determine whether the referenced object currently has a forwarding pointer.

[0101] If not, the referenced object has not yet been copied to the To partition, and thus block 246 is executed to copy the referenced object to the To partition and to add a forwarding pointer to the original copy in the From partition. Control then returns to block 240 to process additional references in the object.

[0102] If, however, the referenced object does have a forwarding pointer, the referenced object has already been copied to the To partition, and as such, block 248 is executed to replace the reference in the currently-processed object with the value stored in the forwarding pointer. In essence, this operation updates the reference to point to the new copy of the object in the To partition. Control then returns to block 240 to process additional references in the object.

[0103] Once all references in the currently-processed object have been processed, block 240 passes control to block 238 to process additional objects in the To partition. Moreover, once all such objects in the To partition have been copied, the copying phase of the garbage collection cycle is complete, and routine 200 terminates.

[0104] FIG. 10 next illustrates swap partitions routine 210 in greater detail. As discussed above, upon completion of the copy roots routine, all reachable objects in the object heap have been copied to the To partition. Thus, routine 210 first executes block 250 to swap the pointers to the From and To partitions, essentially returning all of the reachable objects into a newly-formed From partition for use during the next cycle of the collector thread. All objects that are not reachable, as well as the original copies of the reachable objects (which still include forwarding pointers to the new copies thereof), remain in the space now allocated to the new To partition. While the new To partition can be cleared if desired, typically this step is omitted since the next cycle of the collector thread will simply overwrite any information still remaining in that partition.

[0105] Once the pointers have been swapped in block 250, control passes to block 252 to update all references to incorporate forwarding pointers. Specifically, all references that point to objects having forwarding pointers are updated to store the values associated with those forwarding pointers, essentially updating the references to point to the new copies in the space now allocated to the From partition. Upon completion of block 252, the object heap has been collected, and the current cycle of the collector thread is complete. Thus, as shown in FIG. 8, control returns to block 204 to wait for a triggering event for the next cycle of the collector thread.

[0106] To illustrate the operation of the specific embodiment described above, Table I below illustrates a representative Java language method “containsKey”, provided as a component of a class entitled “Hashtable”, and having a plurality of “HashtableElement” objects:

[0107] Table II below in turn illustrates representative bytecodes generated during compilation of the method illustrated in Table I:

[0108] Based upon the above object code, execution of routine 100 of FIGS. 4A and 4B would create a load store table such as table 75 of FIG. 5, including the data shown therein that indicates that the “table” object is referenced three times (at bytecode offsets 1, 14 and 19), the “tempObject” object is referenced twice (at bytecode offsets 28 and 51), and the “this”, “value”, “next”, and “key” objects are each referenced once (respectively at bytecode offsets 0, 5, 53 and 39). Similarly, routine 100 would create an access order tree such as tree 85 of FIG. 6, indicating the relative access order of the various objects referenced in the method.

[0109] Now turning to FIGS. 12A-12C, a representative garbage collection operation performed on an exemplary object heap 300, including a From partition 302 and a To partition 304, is illustrated. FIG. 12A in particular illustrates the state of From partition 302 prior to garbage collection, when the call stack of one of the threads in the Java virtual machine during the garbage collection cycle is pausing or has the containsKey method on the stack, e.g., as represented by an entry 282 on a call stack 280 in FIG. 11. For this example, “Hashtable” and “table” objects are on the stack as of the initiation of the garbage collection operation.

[0110] As shown in FIG. 12A, based upon the order in which the objects are allocated, the From partition may have a “Hashtable” object 306, a “table” object 308, a pair of “HashtableElement” objects 310, 312, and a pair of objects 314, 316 referenced by the “HashtableElement” objects. As is further shown in FIG. 12A, these objects may be widely dispersed within From partition 302, with additional objects, represented at 318, interspersed therebetween.

[0111] Now turning to FIG. 12B, the result of copying the objects from From partition 302 to To partition 304 (starting at block 218 of FIG. 9A) is illustrated, whereby copies (denoted by primes) are made of the “Hashtable” object 306, “table” object 308, “HashtableElement” objects 310, 312, and objects 314, 316. The object copies are packed together in the To partition, and the copy order is based on breadth first ordering (depth first ordering may also be used). It should be noted that forwarding pointers are added to the objects in the From partition to maintain the references to the copies in the To partition. Also, orphaned objects, represented at 318, are not copied into the To partition, and are therefore discarded when the partitions are swapped.

[0112] Next, as shown in FIG. 12C, the references contained within the objects are cleaned up as discussed above in connection with FIG. 9B, specifically starting with block 238 of routine 208. Upon swapping of the partitions, To partition 304 then becomes the From partition for the next garbage collection cycle.

[0113] Additional modifications may be made to the illustrated embodiments without departing from the spirit and scope of the invention. The invention therefore lies in the claims hereinafter appended.