GB2308689A - Runtime object instance management - Google Patents

Abstract

PROBLEM TO BE SOLVED: To manage an instance of an object in an object-oriented computer system. SOLUTION: The performance of the object and a method in the object are monitored relationally to the performance of a processor and that of a network. Performance information is used for managing the object instance. Especially the object instance is moved, divided or merged. When an object method does not satisfy a performance target during the loading of the object to a current execution environment, an execution environment in which the object attains the performance target is determined and the object is moved to the determined environment.

Description

METHOD AND SYSTEM FOR RUNTINE OBJECT INSTANCZ NANAawMVNT The present invention relates in general to object-oriented computer systems. More specifically, the present invention relates to the distribution of objects in object-oriented computer systems, and in particular, to a method and system for dynamically managing object instances in response to performance of the object's methods.

Reference is made to the following U.S. Patent Applications: SNETHOD AND SYSTEM OF DYNAMICALLY MOVING OBJECTS BETWEEN HETEROGENEOUS EXECUTION ENVIRONMENT8^, docket number CR9-95-010, serial number 0000578098, filed on 27 December 1995; METHOD AND SYSTEM FOR MIGRATING AN OBJECT BZTWZ D A SPLIT STATUS AND A MERGED STATUS, docket number CR9-95-016, serial number 0000579544, filed on 27 December 1995; and 'AUTOMATIC CLIENT-SERVER COMPILER", docket number CR9-95-013, serial number 0000579460, filed on 27 December 1995.

Current computer programming techniques include the use of Object Oriented Programming ('OOP'). Object-Oriented Programming centres on reusable, self-contained, callable program code modules known in the art as 'objects. Such a modular approach makes software development more efficient and reliable through the use and reuse of proven, tested objects.

Each object is designed to accomplish a predefined set of operations through 'methods.2 These methods include programmed tasks for the object to perform when called upon to do so (i.e., invoked). Each particular method is defined within a 'class associated with an object.

A class acts as a template that describes the behaviour of a group of similar objects. An object is instantiated from (or in a runtime instance of) a selected class, and includes methods and attributes (or data) defined in the class.

Object methods are shared resources that may be invoked by other objects throughout the object-oriented computer system. The load on an object (and the corresponding load on the execution environment it is instantiated within) will therefore vary with both the periodicity of invocations of the object and the complexity of methods used within the object. Careful system planning is required such that enough instances of any particular object are available within the execution environments of the object oriented-computer system to handle the presented load.

Conventionally, this planning is performed during a system planning activity, and object instance distribution is fixed during system operations. Thus, unanticipated changes in system configuration, operation, or availability can severely impact object performance.

Disturbances to system performance are currently detectable in a variety of ways. For instance, many schemes exist for monitoring the individual performance of, e.g., processors and networks therebetween.

However, monitoring of objects, as individual entities, has not yet been fully explored. Furthermore, although some system adjustments have been performed in view of monitored system performance (e.g., changing queue weightings and performing alternate network routing), appropriately utilising a variety of performance information for managing the objects and instances thereof, in an object-oriented computer system, is also undeveloped.

According to a first aspect of the present invention, there is provided in an object oriented computer system including a plurality of execution environments and an object having at least one instance executing in at least one execution environment of said plurality of execution environments, a method for managing said object comprising: (a) monitoring runtime performance of said object in said object-oriented computer system; and (b) altering, at runtime, in response to said monitoring, at least one of a number of said at least one instance and/or a number of said at least one execution environment said at least one instance executes in.

According to a second aspect of the present invention, there is provided in an object oriented computer system including a plurality of execution environments and an object having at least one instance executing in at least one execution environment of said plurality of execution environments, a system for managing said object comprising: means for monitoring runtime performance of said object in said objectoriented computer system; and means for altering, at runtime, in response to said monitoring, at least one of a number of said at least one instance and/or a number of said at least one execution environment said at least one instance executes in.

As an enhancement, the at least one instance of the object may comprise a single instance executing within a single execution environment. Further, the altering may comprise moving the single instance from the single execution environment to another execution environment. The single execution environment and the other execution environment may be heterogeneous, and the state of the object may be preserved during the move.

As an enhancement, the at least one instance of the object may comprise a single instance executing within a single execution environment. Further, the altering may comprise splitting the object into multiple instances executing in multiple execution environments.

Moreover, if the at least one instance of the object comprises multiple instances executing in multiple execution environments, the altering may comprise merging the object into a single instance executing within a single execution environment.

As a further enhancement, the object-oriented computer system may include an object manager, and the monitoring may include tracking object manager activity related to the object. Further, the object-oriented computer system may include a runtime optimizer that performs the altering. The monitoring may then include forwarding information obtained from the tracking to the control program for use in the altering. The monitoring may comprise monitoring network parameters related to the object, including, e.g., network latency.

As yet further enhancements, the object includes at least one method, and the monitoring includes maintaining an interaction table including at least one invocation of the method and performance data associated with the at least one invocation. The performance data may include an invoker of the at least one method. Further, the performance data may also include a forward delay incurred transferring the at least one invocation from the invoker to the object. Even further, if the invocation is of a type requiring processing and a response, the performance data further includes a processing delay of the at least one method and a return delay incurred transferring the response to the invoker.

The present invention has several advantages and features associated with it. Performance monitoring techniques for processors, networks and object are combined with techniques for managing object instances, such that dynamic, runtime, object management is achieved.

For example, if an object's methods are not achieving their desired performance goals, the object is relocated to an execution environment within which it is capable of achieving its goals. If such an execution environment can not be found, the object is 'split" into multiple instances, such that collectively, performance goals are attained. If the multiple instances represent too much utilised resource, then instances can be merged, thereby decreasing the numbers thereof.

Dynamic, flexible, performance driven object instance management is thereby attained.

The invention will now be described, by way of example, with reference to the accompanying drawings, in which: Fig. 1 is one example of a computer system useful in implementing the techniques of the present invention; Fig. 2 is one example of an object-oriented computer system useful in implementing the techniques of the present invention; Fig. 3 is one example of an ORB Registration Table used in connection with the techniques of one embodiment of the present invention; Fig. 4 is an example of a Policy Table used pursuant to an embodiment of the present invention; Fig. 5 is one example of a System Performance Table in accordance with one embodiment of the present invention; Fig. 6 is one example of a Network Performance Table pursuant to the techniques of an embodiment of the present invention; Fig. 7 is an example of an Interact ion Table used to track invocations of object methods in connection with one embodiment of the present invention; Fig. 8 is an example of an Invoker Table used to account objects and invokers thereof according to an embodiment of the present invention; Fig. 9 is an example of a Split/Merge Routing Table used to track multiple instances of objects pursuant to one embodiment of the present invention; Fig. 10 is an example of a Split/Merge Policy Table used in determining when to perform split status to merged status object migration according to an embodiment of the present invention; and Figs. ll-lZB depict examples of methods for managing object instances in accordance with the techniques of the present invention.

In U.S. patent applications 'METHOD AND SYSTEM OF DYNAMICALLY MOVING OBJECTS BETWEEN HETEROGEMEOUS EXECUTION ENVIRONMENTS", docket number CR9-95-010, serial number ~~~~~~~~~~~~~~~~~~~~~, , file filed on ~~~~~~~~ and and 'METHOD AND SYSTEM FOR MIGRATING AN OBJECT BETWEEN A SPLIT STATUS AND A MERGED STATUS', docket number CR9-95-016, serial number filed on ~~~~~~~~~~~~~~~~, techniques for managing instances of objects at runtime are disclosed. For example, the aforementioned U.S.

Patent Applications include techniques for moving objects between heterogeneous execution environments, splitting an object into multiple instances thereof, and merging multiple instances of an object into a single instance thereof, at runtime.

The techniques disclosed herein operate in connection with the aforementioned object management techniques. In particular, the techniques disclosed herein determine and affect appropriate object movement, splitting and merging based upon monitored system and object performance. Performance monitoring techniques are combined with particular heuristics and the aforementioned object management techniques to dynamically optimise performance of the object-oriented computer system.

The techniques disclosed herein are described in connection with terminology and resources that will be apparent to one of ordinary skill in the art. In one example, the terminology and resources described herein are associated with the Common Object Request Broker Architecture ("CORBA" - a registered trademark of the Object Management Group, Inc.), an international standard for object management resources. One example of an entity included in CORBA type systems is an Object Request Broker ('ORB"), which is responsible for, e.g., creation, deletion and tracking of objects. A particular implementation of the CORBA standard is International Business Machines' System Object Model (SOM) Objects Toolkit (SOMobjects). Further descriptions of CORBA and SOMobjects may be found in, e.g., 'CORBA - A Guide To Common Object Request Broker Architecture,' by Ron Ben-Natan, McGraw-Hill, 1995 and 'AIX Version 4.1 SOMobjects Base Toolkit User's Guide, IBM, 1993, Publication No. SC23- 2680-01, and 'AIX Version 4.1 SOMobjects Base Toolkit Programmers Reference Manual,' IBM 1993, Publication No. SC23-2681-01, which are incorporated herein by reference in their entireties. CORBA is only one example of an object-oriented environment within which the techniques disclosed herein will operate. The present invention is compatible with any object-oriented environment that includes an object manager (e.g., The Object Request Broker-ORB of CORBA) which enables transmittal of information between objects and provides object location transparency (e.g., 'Microsoft's Common Object Manager environment or the 'Visual Age environment from 'IBM Corporation).

One example of the hardware elements of a computer system used to implement the techniques of the present invention are shown in Fig. 1. A central processing unit ('CPU") 11 provides main processing functionality. A memory 15 is coupled to CPU 11 for providing operational storage of programs and data. Memory 15 may include, for example, random access memory (RAM) or read only memory (ROM ). Nonvolatile storage of, for example, data files and programs is provided by a storage 13 that may include, for example, disk storage. Both memory 15 and storage 13 are computer usable media that may store computer program products as computer readable program code. User input and output are provided by a user input/output (I/O ) facility 19. User I/O facility 19 may include, for example, a graphical display, a mouse and/or a graphics tablet. System input and output are provided by a system I/O facility 17 (e.g., a network adapter). As will be understood in the art, other I/O facilities may be included based upon system configuration (e.g., between storage 13 and CPU 11). As one computer system example, the computer system of Fig. 1 may be an "APTIVA PERSONAL COMPUTER SYSTEM from 'IBM CORPORATIONS executing an 'OS/2 WARP" operating system from "IBM CORPORATION." One example of an object-oriented computer system having multiple execution environments is shown in Fig. 2. Depicted therein is an object-oriented computer system that includes five execution environments, namely three 'INTEL' processor-based workstations (workstation A 35, workstation B 37 & workstation C 39), an 'IBM SYSTEM/390' class mainframe-based host computer ('host") 31 and an 'IBM POWER PC file server 33. Workstations A 35, B 37 and C 39 ('workstations') are designed to, e.g., interact with users, host 31 is intended as, e.g., a transaction processor, and file server 33 is, e.g., a database server that accesses stored information on disks internal thereto.

The execution environments are interconnected by, e.g., a 'TOKEN RING" local area network ('LAN") 41 to facilitate communication therebetween. More particularly, workstation A 35 is attached to LAN 41 through a telecommunications link 43. Despite the particular interconnection topology shown, any conventional hardware/software networking scheme may be used in connection with the techniques disclosed herein.

Host 31, file server 33 and the workstations are part of the object-oriented computer system depicted. In regard thereto, an ORB 45 for the system is contained within host 31. As will be understood in the art, the exact configuration and location of ORB 45 will vary based upon the object-oriented environment utilised.

One feature of the present invention facilitates the dynamic, runtime, movement of an object between execution environments in consideration of performance goals. Several tables are maintained in connection with this feature, and are discussed in detail hereinbelow.

Depicted in Fig. 3 is an ORB Registration Table. As known in the art, the ORB conventionally uses the Registration Table to track the location of each object instantiated in the object-oriented computer system. The 'LOCATION" field contains the name (or other unique identifier) of the execution environment that an object is contained within. For example, as shown, object X is instantiated within host 31.

A Policy Table is maintained for use in determining when the performance of an object is acceptable, and conversely, when the performance of an object is unacceptable. One example of a Policy Table is depicted in Fig. 4. For each object's method subject to performance monitoring and relocation according to the techniques disclosed herein, table entries are defined (e.g., by a system programmer or by operations personnel). The table entries include the name of the object, the name of the method, a maximum interaction time ('MaxIT") and an interaction type. MaxIT is equal to the longest acceptable time for an interaction using the particular object's method. The interaction type defines the type of object interaction and is used in interpreting the MaxIT parameter.

Two interaction types are defined herein. A first interaction type, type 1, is used in connection with methods that receive a message (i.e., from another object), but do not produce a response thereto. A second interaction type, type 2, is used in connection with methods that both receive a message, process the message, and reply with an appropriate response. As explained further hereinbelow, the heuristic used to determine when, and where, an object is moved will vary based upon the object method interaction type.

Several types of performance information are gathered in support of determining when, and where, objects are moved according to the techniques disclosed herein. As a first example, a System Performance Table dynamically records performance data for each individual execution environment of the object-oriented computer system. One example of a System Performance Table with data corresponding to the object-oriented computer system of Fig. 2, is shown in Fig. 5.

Each of the 'Performance' values of the System Performance Table of Fig. 5 is represented in Absolute Units of Work ('AUW). An AUW is a measure of how long it takes each execution environment to perform a designated task (i.e., a benchmark). For example, the AUW could measure how long it takes each execution environment to perform 10,000 floating point multiplications. Whatever benchmark is used, it is executed periodically (e.g., every 10 seconds), on each execution environment, such that the System Performance Table can be constructed, updated as necessary and made available. In one embodiment, the benchmark would be implemented as a common object on each execution environment whose methods execute the benchmark, record the time required to complete it, and return the time value to the invoker. The invoker could invoke the benchmarking objects on the selected periodic basis, and maintain the System Performance Table accordingly (A similar table may also be built using a conventional performance monitor, e.g., 'Resource Management Facility' from 'IBM CORP.").

Besides individual execution environment (i.e., processor) performance, network performance is useful in connection with the techniques of the present invention. The time it takes messages and/or invocations to pass between execution environments affects overall object performance and is an important performance metric in object-oriented computer systems. Pursuant to the present invention, a Network Performance Table maintains such a metric.

One example of a Network Performance Table with data corresponding to the object-oriented computer system of Fig. 2, is shown in Fig. 6.

Each value within the System Performance Table of Fig. 6 represents the time it takes for a predefined network-based activity to occur. For example, each value could represent the time required to send, e.g., 1000 bytes from one execution environment to another execution environment (as shown by the 'diagonal within the Network Performance Table of Fig. 6, it takes zero time to send data to oneself over a network) . Whatever networking benchmark is used, it is executed periodically (e.g., every 10 seconds), on each execution environment, such that the Network Performance Table can be constructed and be made available within the computer system. In one embodiment, the network benchmark would be implemented as an object on each execution environment whose methods execute the network benchmark, record the time required to complete it, and return the time value to the invoker. The invoker could invoke the benchmarking object on each execution environment on the selected periodic time basis, and maintain the Network Performance Table accordingly. Run-time messages may also be monitored to determine network performance.

A further performance monitoring function of the present invention utilises information available within the ORB to maintain an Interaction Table for each object interaction within the object-oriented computer system. The ORB manages each interaction between objects and the methods therein. The functionality of the ORB is extended to maintain a record of each object interaction, e.g., in a form depicted in the Interaction Table of Fig. 7 that is stored in the object-oriented computer system.

The Interaction Table of Fig. 7 includes several information fields for each object interaction. These fields are defined as follows: Seq # A sequence number used to identify each object interaction.

From Obj The source object of the interaction.

To Obj The target object of the interaction.

To Method The target method within the target object of the interaction.

Type The type of interaction (i.e., Type 1 = no response expected; Type 2 = response expected) Start Time The time the interaction was initiated by the source object.

Forward Delay The time occupied in transferring the message/invocation from the source object to the target object (i.e., computed from time stamps in connection with a system clock).

Proc. Time For Type 2 objects, the actual processing time used by the target object in processing the interaction.

Return Delay The time occupied in transferring a response from the target object to the source object (i.e., computed from time stamps in connection with a system clock).

As each interaction occurs, a corresponding entry is added to the Interaction Table. However, the Interaction Table is not permitted to grow unrestrained, and is managed according to list management rules. As a first rule, the interaction table is limited to a predetermined number of interactions (e.g., 100). When the table grows beyond the predetermined limit, the oldest transaction is removed and the newest transaction is added. As a further example rule, when an object is moved between execution environments, all of its entries are removed from the Interaction Table as they represent an instantiation of the object that no longer exists. As yet another rule, only the latest entry for a particular interaction (i.e., defined by from object, to object & to method) is maintained.

Yet another table used in connection with the present invention is the Invoker Table shown in Fig. 8. This table records a list of invokers for each method of each object. Similar to the Interaction Table, the Invoker Table is dynamically maintained by monitoring ORB managed object interactions, and for each interaction, building a non-redundant list of the invokers for each method of each object.

Using the above discussed tables, a mechanism is implemented for moving an object between execution environments when appropriate. In particular, if an object is not achieving its designated performance goals, it is moved to an execution environment where it can attain its goals.

Periodically, the Interaction Table (Fig. 7) is examined, and each method's interaction data is examined to determine if the object is achieving its performance goals. If the object's method is not achieving its goals, the object is moved to an execution environment where its goals are attainable, otherwise, the object is undisturbed.

More particularly, an example process for insuring that methods meet their goals, and for moving objects to a better position if they do not, is depicted in Figs. ll-12B. It is assumed that a method from the Interaction Table of Fig. 7 has already been chosen for examination. As shown in Fig. 11 (STEP 101), an object type (i.e., type 1 or type 2) and desired Interaction Time ('IT") is determined for the current method from the Policy Table of Fig. 4. A test is next performed to determine if the method is of 'type 1 or 'type 2" (INQUIRY 103). For 'type 1' methods, the Interaction Time is compared with the Forward Delay associated with the current method in the Interaction Table. If the Forward Delay exceeds the Interaction Time (INQUIRY 107), the desired performance has not been met, and movement of the object having the subject method is performed (STEP 111). For 'type 2" methods, the Interaction Time is compared with the sum of Forward Delay, Return Delay and Processing Delay associated with the current method in the Interaction Table. If this sum exceeds the Interaction Time (INQUIRY 109), the desired performance has not been met, and movement of the object having the subject method is performed (STEP 111). Otherwise, if performance goals have been met, no action is taken (STEP 105).

One example of the techniques for determining which execution environment of the object-oriented computer system the object having the subject method ('ToObj') should be moved to is depicted in the pseudocode of Figs. 12A-B. To begin, a list of potential target execution environments (PTL') for ToObj is initialised to a null value (STEP 120).

A variable called 'CURLOC' is set to the name of the execution environment that ToObj currently executes on (STEP 121). This name is determined from the ORB Registration Table (Fig. 3). Another list, 'LOCLIST," is initialised to include the names of execution environments from which invocations of any methods of ToObj have originated (STEP 123). This is determined from the Invoker Table shown in, e.g., Fig. 8.

The actual methods invoked are initially stored in a list called SMETHLIST,' similarly constructed from an examination of the Invoker Table (STEP 125).

To continue, a loop is entered for each method in METHLIST, where M is the current method being processed in the loop (STEP 127). A list of potential target execution environments for M, 'PTLM,' is initially set empty (STEP 129). Then, if M is of type 2 (STEP 131 -, e.g., determined from the Policy Table of Fig. 4), a measure of work 'MW' is determined therefor (STEP 133). Particularly, MW is determined by dividing the last processing time 'PT" recorded for M in the Interaction Table (e.g., Fig.

7) by the AUW measure of CURLOC as indicated in, e.g., the System Performance Table of Fig. 5. If M is not of type 2 (STEP 132), MW is set to a null value (STEP 134).

A next loop is entered, which processes each execution environment in the Processor Performance Table, absent CURLOC, where the execution environment being processed is stored in PTSYS (STEP 135). Within the loop, if MW is not null (STEP 137), then the projected response time on system PTSYS is calculated. Specifically, the projected response time is represented by PRrsys which is set to the product of the AUW of PTSYS (i.e., AUWsys) and MW (STEP 139). If MW is null, then PR,,,sys is set to null (STEP 141).

A further nested loop is entered, which processes each execution environment in LOCLIST, where the execution environment being processed is stored in S (STEP 143). A 'to time," TOTIME, is determined as a function of the network delay from S to PTSYS (STEP 145). PR,,,,sys is then incremented by TO~TIME (STEP 147). After that, if M is of type 2 (STEP 149), then a "from time, FROM~TIME, is determined as a function of the network delay from PTSYS to S (STEP 151) and Per,,,, is incremented thereby (STEP 153). To complete the current loop, if PR-sys is greater than the interaction time (i.e., referred to as CRITERION) stored in the policy table for the current method M, then the foregoing nesting level of looping is bypassed via a jump to the outermost loop (STEP 155).

Otherwise, the current loop iterates (i.e., to STEP 143).

The foregoing nesting level of looping (i.e., the loop staring with STEP 135) is completed by incrementing PTSYS by PTL~M (STEP 157). The loop then iterates (to STEP 135).

The outermost loop continues by setting PTL to PTL~M (STEP 161) if PTL was null (STEP 159). If PTL is non-null, then PTL is set to the logical 'set' intersection of itself and PTL~M (STEP 163). As a result of the foregoing, PTL contains a list of acceptable target execution environments for all methods of ToObj that have been used. Selection of the execution environment to which the object will be moved can then by made from this list by, e.g., random selection, or a predetermined preference policy for execution environments, or an affinity for a particular execution environment as described in the aforementioned U.S.

patent application entitled 'AUTOMATI not satisfied is removed from all the Invoker Table (e.g., Fig. 8) entries for all of M's methods, and a split instance entry is created in the Invoker Table for an instance to be created as a split instance per the techniques described below. Then, the invoker deleted from M's entries in the invoker table is added as an entry for the split instance in the invoker table. The above-described techniques (Figs. 12-12A) are then applied to determine an execution environment for a split instance of M, and the split instance is created using the split/merge techniques of the aforementioned U.S. patent application entitled 'METHOD AND SYSTEM FOR MIGRATING AN OBJECT BETWEEN A SPLIT STATUS AND A MERGED STATUS". If M does not have any other invokers, then M is deleted. The "split criteria' of the Split/Merge Policy Table of Fig. 10 is used as 'MaxIT' in the above-referenced process, and the split instance is created in the location determined thereby. Creation of a split instance of M is complete.

Similarly, once a method is 'split,' it may become desirable to 'merge" the object into fewer instances thereof. For example, if a split instance Sl of object M can not be relocated to an execution environment that satisfies its performance criteria, the following process is performed. If the merged instance M of Si does not exist, then the above described techniques are used to create M in the determined location. A further step includes the creation of entries for M in the Invoker Table (Fig. 8). The entires for Si are moved to the created entry for M, and the entires for Si are deleted. The 'merged criteria" of the Split/Merge Policy Table of Fig. 10 is used as 'MaxIT," and the merged instance is created in the location determined thereby. Thereafter, S, is merged into M using the techniques described in the aforementioned U.S. patent application entitled 'METHOD AND SYSTEM FOR MIGRATING AN OBJECT BETWEEN A SPLIT STATUS AND A MERGED STATUS'.

Although in the above-described techniques, the performance of each object in the Interaction Table (Fig. 7) is evaluated periodically, other evaluation techniques are possible. For example, the performance of each object/method could be evaluated upon every invocation. Also, the process carrying out the above described steps in implementable as, e.g., an object or collection of objects within the object-oriented computer system. In one embodiment, these objects would be implemented within the same execution environment as the ORB to facilitate expedient access thereto in connection with management of the Interaction and Invoker Tables.

Described above are examples of techniques for dynamically managing the distribution of objects within an object-oriented computer system, at runtime. It will be apparent to those of ordinary skill in the art that the above-described flows and sequences of steps are only examples.

There can be many variations to the above, including, for instance, processing more or less than the steps described above, modifying one or more of the steps, or changing the order of some steps without departing from the true spirit and scope of the present invention. For example, invoking objects may be moved instead of invoked object using the techniques disclosed above. These variations are, therefore, considered a part of the claimed invention.

Claims (25)

1. In an object oriented computer system including a plurality of execution environments and an object having at least one instance executing in at least one execution environment of said plurality of execution environments, a method for managing said object comprising: (a) monitoring runtime performance of said object in said objectoriented computer system; and (b) altering, at runtime, in response to said monitoring, at least one of a number of said at least one instance and/or a number of said at least one execution environment said at least one instance executes in.

2. A method according to claim 1, wherein said at least one instance of said object comprises a single instance executing within a single execution environment, and wherein said altering comprises moving said single instance from said single execution environment to another execution environment of said plurality of execution environments.

3. A method according to claim 2, wherein said moving comprises moving said single instance from said single execution environment to said another execution environment, wherein said another execution environment and said single execution environment are heterogeneous.

4. A method according to claim 3, wherein said moving includes preserving a state of said object during said moving between said single execution environment and said another execution environment.

5. A method according to claim 1, wherein said at least one instance of said object comprises a single instance executing within a single execution environment, and wherein said altering comprises splitting said object into multiple instances executing in multiple execution environments of said plurality of execution environments.

6. A method according to claim 5, wherein said splitting includes copying a state of said single instance of said object to said multiple instances thereof.

7. A method according to claim 5, wherein despite said splitting, invocation of said object is performable by invokers thereof in a same way as prior to said splitting.

8. A method according to claim 5, wherein said splitting comprises maintaining said single instance executing within said single execution environment.

9. A method according to claim 5, wherein said splitting comprises removing said single instance executing within said single execution environment.

10. A method according to claim 1, wherein said at least one instance of said object comprises multiple instances executing in multiple execution environments, and wherein said altering comprises merging said object into a single instance executing within a single execution environment.

11. A method according to claim 10, wherein said merging includes consolidating a state of said multiple instances of said object and impressing said state into said single instance of said object.

12. A method according to claim 10, wherein despite said merging invocation of said object is performable by invokers thereof in a same way as prior to said merging.

13. A method according to any one of the preceding claims, wherein said object oriented computer system includes an object manager (45), and wherein said monitoring comprises tracking object manager activity related to said object.

14. A method according to claim 13, wherein said object oriented computer system includes a runtime optimizer that performs said altering, and said monitoring includes forwarding information obtained from said tracking to said runtime optimizer for use in said altering.

15. A method according to any one of the preceding claims, wherein said monitoring comprises monitoring network parameters related to said object.

16. A method according to claim 15, wherein said network parameters include network latency.

17. A method according to any one of the preceding claims, wherein said monitoring comprises monitoring performance of said at least one execution environment said at least one instance executes in.

18. A method according to any one of the preceding claims, wherein said object includes at least one method, and wherein said monitoring includes maintaining an interaction table including at least one invocation of said method and performance data associated with said at least one invocation.

19. A method according to claim 18, wherein said performance data includes an invoker of said at least one method.

20. A method according to claim 19, wherein said performance data further includes a forward delay incurred transferring said at least one invocation from said invoker to said object.

21. A method according to claim 20, wherein said invocation is of a type requiring processing and a response, and wherein said performance data further includes a processing delay of said at least one method and a return delay incurred transferring said response to said invoker.

22. A method according to any one of claims 18 to 21, wherein said monitoring includes maintaining a policy table including said at least one method and a goal interaction time for each of said at least one method.

23. A method according to claim 22, wherein said monitoring includes comparing at least one of said goal interaction times to said performance data to determine if performance of said object is satisfactory.

24. In an object oriented computer system including a plurality of execution environments and an object having at least one instance executing in at least one execution environment of said plurality of execution environments, a system for managing said object comprising: means for monitoring runtime performance of said object in said object-oriented computer system; and means for altering, at runtime, in response to said monitoring, at least one of a number of said at least one instance and/or a number of said at least one execution environment said at least one instance executes in.

25. A system according to claim 24 arranged to carry out a method according to any one of claims 1 to 23.