The present invention relates to digital processing systems. More specifically, the invention relates to dynamic dispatch in digital processing systems.
Objects, in object-oriented systems, are data structures that encapsulate data and methods that operate on that data. Classes define types of objects. Objects are instances of classes. Methods define actions the class can perform. Classes can be organized into a hierarchy that includes a parent class at the root. Children of the parent class may inherit methods and data from the parent, redefine methods and data, or introduce new methods and data. The hierarchy can grow to arbitrary complexity. Methods may be distinguished by using a method signature that includes the combination of the method's name and the number, type, and order of parameters. The method signature may also include, for example, a visibility modifier (e.g., public, private, protected), a return type, a throws clause, or some other value. To invoke a method, a message is sent to an object, which selects the method to execute. The method address may be found at runtime through a technique known as dynamic dispatch. Dynamic dispatching typically entails extracting the data type (class) of the object and mapping the method signature to a method address. The inheritance property of classes occasionally makes method-lookup somewhat complicated. If a method-lookup fails, the method-lookup is repeated at the parent of the object's class, continuing up the class hierarchy until the method-lookup succeeds or the root of the hierarchy is reached.
Inline caching of method addresses is first described by Deutsch and Shiffman in “Efficient Implementation of the Smalltalk-80 System,” Conference Record of the Eleventh Annual ACM Symposium on Principles of Programming Languages, pp. 297-302, Salt Lake City, Utah, 1984, which is incorporated herein by reference in its entirety. In accordance with the inline caching technique, when the method-lookup succeeds, a direct call to the class's method may be written into computer code at the dispatch point (e.g., the point from which the method call was made). Subsequent method calls may be more efficient since method-lookup can be avoided as long as the objects dispatched upon have the same type. Unfortunately, cache size adversely impacts the memory requirements of programs.
Dynamic dispatching is a process of invoking a method on an object, where the method address is determined (deterministically) at runtime by the signature of the method and dynamic type (e.g., class) of the object. Once the method is known, computer code associated with the called method may be written into the computer code at the dispatch point. Subsequent invocations of the method are more efficient because the computer code associated with the method is at the dispatch point (inline caching). However, this efficiency comes at the expense of increased memory usage.
A technique for optimizing dynamic dispatch in object oriented systems includes inline caching. In one embodiment of the invention, an inline cache includes an inline reference to a called method. The inline reference may be direct or indirect. For example, the inline reference may be directed to a cache state. The cache state may include the called method address and the prerequisite type used for cache validation. In an alternative embodiment, the cache state may itself include an inline cache.
The memory requirements of the inline reference and the cache state may not be significantly less than the memory requirements associated with an inline cache (and could even be more). However, if multiple cache states share certain characteristics, such as, for example, identical cached method addresses and prerequisite types, each inline reference can be directed to the same cache state. Assuming the number of distinct cache states is less than the number of distinct dispatch points, the use of an inline reference should reduce memory requirements.
Embodiments of the invention are illustrated in the figures. However, the embodiments and figures are illustrative rather than limiting; they provide examples of the invention.
In operation, when the method 162 executes commands associated with the computer code 164 to call the method 166, the point at which the method 162 calls the method 166 may be referred to as a dispatch point. The dispatch point is represented in
In operation, the method 166, once called, executes one or more commands. When the method 166 is done executing, the method 166 passes control back to the calling method 162. The point at which the method 166 finishes may be referred to as an exit point. The exit point is represented in
In an embodiment, a state acquisition engine 168 intercepts the method call from the method 162 to the method 166. Method-call interception (MCI) is a well-known technique for facilitating runtime adaptation for object-oriented software systems. Since the technique is well-known, MCI is not described in detail herein.
The state acquisition engine 168 determines state information, which may include, for example, object data, method data, and other data. In an embodiment, the other data may include data associated with environment variables or other parameters. The state acquisition engine 168 may perform method-lookup using the method signature at the dispatch point 164 and the type of object dispatched upon to find a method address.
Calls from the method 162 to the method 166 may be local. For example, methods 162 and 166 may be stored locally in non-volatile storage or memory. In an alternative, calls from the method 162 may extend from a remote computer location to or from, for example, a server computer across a LAN or other network.
While there is no specific requirement as to the format of the state information 170, the state information should be sufficient to map the method signature for the object type of the object dispatched upon to a method address. Advantageously, this can make method-lookup unnecessary for subsequent method calls, so long as the state information remains valid. In an embodiment, the object type may be referred to as associated with the method 166. The method 166 may or may not be encapsulated within an object having the object type with which the method 166 is associated. In another embodiment, the method 166 may or may not be inherited by the object having the object type. In another embodiment, the method 162 could also be associated with the object type.
The cache state 174 calls the method 166. After the method 162 is adapted, the inline reference 172 may be referred to as the dispatch point for the method 162. The enter and exit points of the method 166 are unchanged. The cache state 174 is interposed between the dispatch point of the method 162 and the enter point of the method 166.
Data from the cache state 174 could be incorporated into the method 162 as an inline cache. However, in an object-oriented system, the number of cache states is typically less than the total number of dispatch points. Accordingly, if data from each of the cache states is written into each method at each of the dispatch points, memory resources must be allocated for this purpose. An inline reference to a shared cache state can ameliorate these memory resource requirements.
In the example of
In the example of
In operation, when a method 162 reaches the dispatch point, the inline reference directs the method 162 to the appropriate cache state. Since the computer code at the dispatch point has already been adapted to direct the method 162 to the appropriate cache state, no method-lookup is required at the dispatch point.
In an embodiment, the object dispatched upon may change. In this embodiment, some form of method validation may be conducted before invoking the method 166. Method validation may, for example, include checking the object dispatched upon to ensure that the object type is the same as the object type associated with the cache state. If the object type of the object dispatched upon and the object type associated with the cache state are different, the inline reference may be changed to reference a more appropriate cache state. If, on the other hand, the object type of the object dispatched upon and the object type associated with the cache state match, then the method 166 can be invoked without a method lookup.
In an embodiment, in operation the method validation engine 180 checks the cache state 174 each time a method call is initiated from the dispatch point of a calling method 162. For example, the method validation engine 180 may check the object type of the object dispatched upon and compare the object type to the object type associated with the cache state 174. If the object types match then, at least in this example, the method is validated and the called method 166 is invoked from the cache state 174. If the object types do not match, then the method call is not validated.
In this embodiment, when the method validation engine 180 determines that a method call is not validated, the method validation engine 180 may consult the hash table 182 to find a cache state that is valid for the method call. Cache states may be represented as entries in the hash table 182. The hash code of the hash table 182 may be a function of a method signature and object type. The method validation engine 180 can determine the method signature from, for example, the method call from the method 162.
In an embodiment, the method validation engine 180 can determine object type from, for example, the object dispatched upon. Accordingly, the method validation engine 180 can calculate the hash code and use the hash code to obtain a valid mapping of the method signature and the object type to a target cache state, if the target cache state exists in the hash table 182. If the method validation engine 180 cannot determine the target cache state using, for example, the hash table 182, then a new cache state may be created in a manner similar to that described with reference to
When the method validation engine 180 knows a valid cache state by, for example, finding the valid cache state in the hash table 182 or by creating a new cache state, the inline reference 172 can be changed to reference the valid cache state.
As illustrated in
In an embodiment, when a cache state has no methods pointing to it, the cache state may be deleted. For example, if the inline reference 172 in
In this embodiment, the flowchart starts at optional module 202 with instantiating an object, wherein the instance of the object includes a first method having a dispatch point to a second method. The object may be instantiated from a class. The class from which the object is instantiated may determine the object type associated with the object. In an embodiment, the instantiation of the object is optional. For example, the first method may or may not be included in an instantiated object.
In the example of
In an embodiment, state may include an object type associated with the second method. In another embodiment, the object type may be associated with the object encapsulating the first method. In another embodiment, the object type may be associated with an object to which a method call is directed. In another embodiment, the object type may be associated with an object from which the method call is derived.
In addition, the state may include a method signature associated with the method-call. In an embodiment, the method signature may be determined from the first method. For example, the first method may include computer code intended to invoke the second method that includes a method name, method parameters, and defines types for the parameters. This data may be used to determine a method signature.
In this embodiment, the flowchart ends at module 212 with adapting the first method to include at the dispatch point an inline reference to a state cache associated with the determined state.
In this embodiment, the flowchart begins at module 214 with invoking a first method that includes an inline cache pointing toward a cache state. In an embodiment, the inline cache may include only an inline reference directed to the cache state. In an alternative embodiment, the inline cache may include, for example, an inline reference directed to the cache state.
In this embodiment, the flowchart continues at module 216 with following the inline cache to the cache state. Following the inline cache may involve, for example, following an inline reference.
In this embodiment, the flowchart continues at module 218 with performing method validation to ensure that state associated with the cache state is valid. Performing method validation is not necessary if state does not change. However, it is possible that state will change between the time the method call is made a first time (and state is cached) and the time the method call is made a second time. For the purposes of example in
In this embodiment, the flowchart ends at module 220 with invoking a second method from the cache state. The cache state may make a method call to the second method. The cache state may include a method signature associated with the second method for, for example, an object type. The object type associated with the cache state may be similar to the object type associated with the second method. In an embodiment, the object types are associated with objects instantiated from identical classes.
In another embodiment, the object types are associated with objects instantiated from related classes. For example, a first class may be a parent that encapsulates the second method and the second class may be a child that inherits the second method. When object types are referred to as being “similar,” this is intended to mean the object types are associated with either identical classes or related classes. In an embodiment where the object types are always associated with identical classes, the object types may still be referred to as similar.
In another embodiment, the cache state may include an inline cache that has computer code associated with the second method, as described with reference to
The following description of
The web server 704 is typically at least one computer system which operates as a server computer system and is configured to operate with the protocols of the world wide web and is coupled to the Internet. The web server system 704 can be a conventional server computer system. Optionally, the web server 704 can be part of an ISP which provides access to the Internet for client systems. The web server 704 is shown coupled to the server computer system 706 which itself is coupled to web content 708, which can be considered a form of a media database. While two computer systems 704 and 706 are shown in
Access to the network 702 is typically provided by Internet service providers (ISPs), such as the ISPs 710 and 716. Users on client systems, such as client computer systems 712, 718, 722, and 726 obtain access to the Internet through the ISPs 710 and 716. Access to the Internet allows users of the client computer systems to exchange information, receive and send e-mails, and view documents, such as documents which have been prepared in the HTML format. These documents are often provided by web servers, such as web server 704, which are referred to as being “on” the Internet. Often these web servers are provided by the ISPs, such as ISP 710, although a computer system can be set up and connected to the Internet without that system also being an ISP.
Client computer systems 712, 718, 722, and 726 can each, with the appropriate web browsing software, view HTML pages provided by the web server 704. The ISP 710 provides Internet connectivity to the client computer system 712 through the modem interface 714, which can be considered part of the client computer system 712. The client computer system can be a personal computer system, a network computer, a web TV system, or other computer system. While
Similar to the ISP 714, the ISP 716 provides Internet connectivity for client systems 718, 722, and 726, although as shown in
Client computer systems 722 and 726 are coupled to the LAN 730 through network interfaces 724 and 728, which can be ethernet network or other network interfaces. The LAN 730 is also coupled to a gateway computer system 732 which can provide firewall and other Internet-related services for the local area network. This gateway computer system 732 is coupled to the ISP 716 to provide Internet connectivity to the client computer systems 722 and 726. The gateway computer system 732 can be a conventional server computer system.
Alternatively, a server computer system 734 can be directly coupled to the LAN 730 through a network interface 736 to provide files 738 and other services to the clients 722 and 726, without the need to connect to the Internet through the gateway system 732.
In the example of
The computer 742 interfaces to external systems through the communications interface 750, which may include a modem or network interface. It will be appreciated that the communications interface 750 can be considered to be part of the computer system 740 or a part of the computer 742. The communications interface can be an analog modem, isdn modem, cable modem, token ring interface, satellite transmission interface (e.g. “DirecPC”), or other interfaces for coupling a computer system to other computer systems.
The processor 748 may be, for example, a conventional microprocessor such as an Intel Pentium microprocessor or Motorola power PC microprocessor. The memory 752 is coupled to the processor 748 by a bus 760. The memory 752 can be dynamic random access memory (dram) and can also include static ram (sram). The bus 760 couples the processor 748 to the memory 752, also to the non-volatile storage 756, to the display controller 754, and to the I/O controller 758.
The I/O devices 744 can include a keyboard, disk drives, printers, a scanner, and other input and output devices, including a mouse or other pointing device. The display controller 754 may control in the conventional manner a display on the display device 746, which can be, for example, a cathode ray tube (CRT) or liquid crystal display (LCD). The display controller 754 and the I/O controller 758 can be implemented with conventional well known technology.
The non-volatile storage 756 is often a magnetic hard disk, an optical disk, or another form of storage for large amounts of data. Some of this data is often written, by a direct memory access process, into memory 752 during execution of software in the computer 742. One of skill in the art will immediately recognize that the terms “machine-readable medium” or “computer-readable medium” includes any type of storage device that is accessible by the processor 748 and also encompasses a carrier wave that encodes a data signal.
Objects, methods, inline caches, cache states and other object-oriented components may be stored in the non-volatile storage 756, or written into memory 752 during execution of, for example, an object-oriented software program. In this way, the components illustrated in, for example,
The computer system 740 is one example of many possible computer systems which have different architectures. For example, personal computers based on an Intel microprocessor often have multiple buses, one of which can be an I/O bus for the peripherals and one that directly connects the processor 748 and the memory 752 (often referred to as a memory bus). The buses are connected together through bridge components that perform any necessary translation due to differing bus protocols.
Network computers are another type of computer system that can be used with the present invention. Network computers do not usually include a hard disk or other mass storage, and the executable programs are loaded from a network connection into the memory 752 for execution by the processor 748. A Web TV system, which is known in the art, is also considered to be a computer system according to the present invention, but it may lack some of the features shown in
In addition, the computer system 740 is controlled by operating system software which includes a file management system, such as a disk operating system, which is part of the operating system software. One example of an operating system software with its associated file management system software is the family of operating systems known as Windows® from Microsoft Corporation of Redmond, Wash., and their associated file management systems. Another example of operating system software with its associated file management system software is the Linux operating system and its associated file management system. The file management system is typically stored in the non-volatile storage 756 and causes the processor 748 to execute the various acts required by the operating system to input and output data and to store data in memory, including storing files on the non-volatile storage 756.
Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.
It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.
The present invention, in some embodiments, also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-roms, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the methods of some embodiments. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language, and various embodiments may thus be implemented using a variety of programming languages.
While this invention has been described by way of example in terms of certain embodiments, it will be appreciated by those skilled in the art that certain modifications, permutations and equivalents thereof are within the inventive scope of the present invention. It is therefore intended that the following appended claims include all such modifications, permutations and equivalents as fall within the true spirit and scope of the present invention; the invention is limited only by the claims.
This application is a Continuation of U.S. patent application Ser. No. 11/100,985, filed Apr. 6, 2005, which is a Continuation of U.S. patent application Ser. No. 10/991,444, filed Nov. 17, 2004, which is a Continuation of U.S. patent application Ser. No. 10/016,794, filed Oct. 29, 2001, which issued as U.S. Pat. No. 6,964,039 on Nov. 8, 2005, and which claims priority from U.S. Provisional Patent Application No. 60/255,096, filed Dec. 13, 2000, and U.S. Provisional Patent Application No. 60/555,774, filed Mar. 23, 2004, and U.S. patent application Ser. No. 11/112,967, filed Apr. 22, 2005, all of which are being incorporated herein.
Number | Date | Country | |
---|---|---|---|
60255096 | Dec 2000 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 11100985 | Apr 2005 | US |
Child | 11495293 | Jul 2006 | US |
Parent | 10991444 | Nov 2004 | US |
Child | 11100985 | Apr 2005 | US |
Parent | 10016794 | Oct 2001 | US |
Child | 10991444 | Nov 2004 | US |