MXPA06007915A - Method and system for a grid-enabled virtual machine with movableobjects - Google Patents

Abstract

A method, an apparatus, a computer program product, and a data processing system provide for operation of a virtual machine with embedded functionality for interoperating with other virtual machines in a computational grid. A plurality of virtual machines are run on one or more devices within a data processing system;each virtual machine in the plurality of virtual machines incorporates functionality for interoperating and associating with other virtual machines in a virtual machine cluster in a grid-like manner. Each virtual machine in the virtual machine cluster acts as a node within the virtual machine cluster. A virtual machine manages its objects in association with an object group, and each virtual machine may manage multiple object groups. The virtual machines share information such that the object groups can be moved between virtual machines in the virtual machine cluster, thereby allowing the virtual machine cluster to act as one logical virtual machine.

Description

METHOD AND SYSTEM FOR A VIRTUAL MACHINE ACTIVATED BY GRID WITH MOBILE OBJECTS BACKGROUND OF THE INVENTION FIELD OF THE INVENTION The present invention relates to an improved data processing system and in particular, to a method and apparatus for data transfer and execution of programs by multiple computers.

DESCRIPTION OF THE RELATED TECHNIQUE The wide adoption of technology related to the Internet and related to the global network has allowed the growth of a global network of interconnected computers that are physically supported by many thousands of organizations and companies and many millions of individuals. Recently, companies have struggled to organize the computational capacity of many computers in a grid, which is a logical organization of many computers to provide the ability to collectively share computing capacity and data storage capacity while maintaining autonomous local control over individual computers. For example, many companies are cooperating within the Global Grid Forum, which is supported by GGF, Inc., to develop community-led standards for grid computing. The Globus ProjectMR is an effort that has been supported by government agencies, corporations, and universities to develop grid-related technologies, which has resulted in the Open Grid Services Architecture (OGSA), which is an initiative to incorporate grid concepts into a service-oriented structure based on global network services. The Globus Toolkit® is an implementation of the Open Grid Service Architecture that provides program programming tools and programming systems or software to develop grid-enabled applications, and the Java® Community Grid Team (CoG) is the portion of Globus Toolkit® that provides access to grid services through the Java® structure. Although the Java® CoG team supports a Java® application to access grid services, the Java® CoG does not incorporate the computational features of a grid into a Java® virtual machine (JVM). Therefore, it would be advantageous to have a method, a system, an apparatus, and / or a computer program product that incorporates the computational characteristics of a grid into a virtual machine. It would be particularly advantageous to effect the administration of objects within a virtual machine so that the virtual machine can be implemented within a grid computing environment that changes dynamically.

SUMMARY OF THE INVENTION A method, an apparatus, a computer program product and a data processing system provide the operation of a virtual machine with included functionality to interoperate with other virtual machines in a computational grid. A plurality of virtual machines operates on one or more devices within a data processing system; each virtual machine in the plurality of virtual machines incorporates the functionality to interoperate and associate with other virtual machines in a set of virtual machines in a form similar to a grid. Each virtual machine in the set of virtual machines acts as a node within the set of virtual machines. A virtual machine manages its objects in association with a group of objects, and each virtual machine can manage groups of multiple objects. Virtual machines share information, so that groups of objects can move between the virtual machines in the set of virtual machines, thus allowing the set of virtual machines to act as a logical virtual machine. The image of a single application that conforms to a typical application model can be executed within the set of virtual machines activated by grid in such a way that allows the execution of the application to cover multiple cases of a virtual machine activated by grid, thus allowing the Application execution encompasses multiple devices.

BRIEF DESCRIPTION OF THE DRAWINGS It is believed that the novel features of the invention are set forth in the appended claims. The invention itself, the additional objects and advantages thereof will be better understood with reference to the following detailed description when read in conjunction with the accompanying drawings, wherein: Figure IA describes a typical network of data processing systems, each one of which may implement the present invention; Figure IB describes a typical computer architecture that can be used within the data processing system in which the present invention can be implemented; Figure 2 depicts a block diagram showing a set of virtual machines in a distributed data processing system according to an implementation of the present invention; Figure 3A describes a block diagram showing the components and / or information that can be used to imp a virtual machine as a virtual machine grouped according to an implementation of the present invention; Figures 3B-3D describe a set of block diagrams showing the transfer of groups of objects between grouped virtual machines; Figure 4 depicts a flow chart showing a process for initializing a primary cJVM node; Figure 5A describes a flow chart showing a process in a primary cJVM for assigning a unique cJVM identifier to a non-primary cJVM being initialized; Figure 5B depicts a flow chart showing an alternative process in a primary cJVM for assigning a unique cJVM identifier to a non-primary cJVM being initialized; Figure 6 depicts a flow chart illustrating a process in a primary cJVM for assigning a unique object group identifier to a non-primary cJVM; Figure 7 depicts a flow chart showing a process in a primary cJVM to pde information about the cJVM group to a non-primary cJMV; Figure 8 describes a flowchart that shows a process in a primary cJVM to change an execution status of a non-primary cJVM; Figure 9 describes a flow chart showing a process in a primary cJVM to change a migration status of a group of objects; Figure 10 depicts a flow chart showing a process for initializing a non-primary cJVM node; Figure 11 depicts a flow chart illustrating a process on a clustered virtual machine during which a line was constructed; Figure 12 describes a flow chart showing a process on a clustered virtual machine during which a line was destroyed; Figure 13 describes a flow chart showing a process on a clustered virtual machine during which an object was constructed; Figure 14 describes a flow chart showing a process on a clustered virtual machine to handle access to the objects; Figure 15 describes a flow chart showing a process on a local clustered virtual machine to migrate a group of objects to a remote clustered virtual machine; Figure 16 describes a flow diagram that shows a process on a local clustered virtual machine to accept the migration of a group of objects from a remote clustered virtual machine; Figure 17 describes a flow chart showing a process on a local clustered virtual machine to migrate a line to a remote clustered virtual machine; Figure 18 describes a flow chart showing a process on a local clustered virtual machine to accept the migration of a line from a remote clustered virtual machine; Figure 19 describes a flow chart showing a process on a local clustered virtual machine to perform an interrupt operation on a clustered virtual machine; Figure 20 describes a flow chart showing a process on a local clustered virtual machine to collect load or operation information from a remote clustered virtual machine; Figure 21 describes a flow chart showing a process on a local clustered virtual machine to respond to a request from a virtual machine grouped by the current load or operation information in a local clustered virtual machine; Figure 22 describes a flow diagram that shows a process on the local clustered virtual machine to determine the migration of lines and / or groups of objects from the local clustered virtual machine to a remote clustered virtual machine according to the loading and operation information; and Figure 23 describes a block diagram showing the execution of a single application image encompassing grid-enabled, multiple virtual machines in a single logical virtual machine on multiple devices.

DETAILED DESCRIPTION OF THE INVENTION In general, devices that may comprise or relate to the present invention include a wide variety of data processing technologies. Therefore, as background, a typical organization of physical computing or hardware components and programming and software systems or systems within a distributed data processing system is described before describing the present invention in greater detail. Referring now to the Figures, Figure 1 describes a typical network of data processing systems, each of which can implement a portion of the present invention. The distributed data processing system 100 contains network 101, which is a means that can be used to provide communication links between; several devices and computers connected together within the distributed data processing system 100. The network 101 may include permanent connections, such as wired or fiber optic cables, or temporary connections established through telephone or wireless communications. In the described example, the server 102 and the server 103 are connected to the network 101 together with the storage unit 104. In addition, the clients 105-107 are also connected to the network 101. The clients 105-107 and the servers 102 -103 can be represented by a variety of computing devices such as large computers, personal computers, personal digital assistants (PDA), etc. In the distributed data processing system 100, it can include servers, clients, routers, other additional devices and person-to-person architectures that are not displayed. In the described example, a distributed data processing system 100 may include the Internet with a network 101 representing a global collection of networks and gateways that use various protocols to communicate with each other, such as the Lightweight Directory Access Protocol ( LDAP), Transport Control Protocol / Internet Protocol (TCP / IP), Hypertext Transport Protocol (HTTP), Wireless Application Protocol (WAP), etc. By Of course, as a distributed data processing system 100 also includes a number of different types of networks, such as, for example, an intranet, a local area network (LAN), or a wide area network (WAN). For example, server 102 directly supports client 109 and network 110, which incorporates wireless communication links. The telephone activated by the network 111 connects to the network 110 through the wireless link 112, and the PDA 113 connects to the network 110 through the wireless link 114. The telephone 111 and the PDA 113 can also directly transfer data between yes through wireless link 115 using appropriate technology, such as Bluetooth ™ wireless technology to create so-called personal area networks (PAN) or personal ad-hoc networks. In a similar way, the PDA 113 can transfer data to the PDA 107 via the wireless communication link 116. The present invention could be implemented in a variety of physical computing or hardware component platforms. Figure 1A is intended to be an example of a heterogeneous computing environment and not an architectural limitation of the present invention. Referring now to Figure IB, a diagram describes a typical computer architecture in a data processing system, such as that shown in Figure IA, in which the present invention can be implemented. The data processing system 120 contains one or more central processing units (CPU) 122 connected to the channel of the internal system 123, which interconnects the random access memory (RAM) 124, the read only memory 126, and the input / output adapter 128, which supports several devices 1 / 0, such as the printer 130, the disk drives 132, or other devices not shown, such as an audio output system, etc. The channel of the system 123 also connects the communication adapter 134 that provides access to the communication link 136. The user interface adapter 148 connects various user devices, such as the keyboard 140 and the mouse 142, or other devices not shown, such as a touch sensitive screen, style, microphone, etc. The display adapter 144 connects the channel of the system 123 to the display device 146. Those skilled in the art will appreciate the physical computing or hardware components in Figure IB may vary depending on the implementation of the system. For example, the system may have one or more processors, such as an Intel® Pentium®-based processor and a digital signal processor (DSP) and one or more types of volatile and non-volatile memory. Other peripheral devices may be used in addition to or in place of the physical computing or hardware components described in Figure IB. It does not mean that the examples described imply architectural limitations with respect to the present invention. In addition to being able to be implemented in a variety of physical computing or hardware component platforms, in the present invention they can be implemented in a variety of programming environments and programming or software systems. A typical operating system can be used to control the execution of the program within each data processing system. For example, one device can run a Unix® operating system while another device contains a simple Java® execution environment. A platform in the form of a representative computer may include a search engine, which is a program application and programming system or well-known software for accessing hypertext documents in a variety of formats and languages, such as graphic files, file processing words, Extensible Marker Language (XML), Hypertext Marker Language (HTML), Manual Device Marker Language (HDML), Wireless Marker Language (WML), and various other formats and file types.

Virtual Machine Group / Grid The present invention can be implemented on a variety of physical computing or hardware component platforms and software and programming systems and programs, as described above with respect to the Figure IA and Figure IB. More specifically, although the present invention is directed to an improved virtual machine that includes computational features of a grid within the enhanced virtual machine, so that the enhanced virtual machine can interact with similar enhanced virtual machines in a manner similar to a virtual machine. grid, as described with respect to the remaining figures. Although the following figures are described as incorporating Java® technology so that the present invention can be implemented as enhanced Java® virtual machines (JVMs), the present invention can be implemented in conjunction with the technology for other types of virtual machines . Referring now to Figure 2, a block diagram illustrates a group / grids of virtual machines in a distributed data processing system according to an implementation of the present invention. The network 200 connects a set of virtual machines 201-205; the network 200 is similar to the network 101 of Figure 1, and the virtual machines 201-205 can be supported on a variety of devices, such as any of the devices that are shown in Figure 1. In an introductory fashion of the terminology, A group is a set of two or more entities that interact. A group of virtual machines can be referred to as a group of virtual machines, a grid of virtual machines, or a logical virtual machine. A single virtual machine that contains functionality to operate in a group / grid can be referred to as a clustered virtual machine or a grid-enabled virtual machine. A single virtual machine that is included within a group / grid can be referred to as a clustered virtual machine or a virtual machine included in a grid. As noted above, the present invention can be implemented within a Java® environment using Java® virtual machines that have been improved to include functionality to implement an embodiment of the present invention. Alternatively, the present invention can be implemented within library extensions of the Java® class. In this way, the terminology that was previously provided can be used within a Java® context. Here later, a grid-enabled JVM or a JVM included in a grid is referred to as a gJVM. Figure 2 shows the network 200 that connects the group of gJVM that contains the gJVM 201-205. A single clustered virtual machine or a single virtual machine included in a grid can be referred to as a node within a given group of virtual machines, a virtual machine grid, or a given logical virtual machine. In the example shown in Figure 2, a set of virtual machines interacts as multiple nodes within a single group of virtual machines in a way similar to a grid. The present invention supports a plurality of nodes in a group of virtual machines, and a distributed data processing system that can support more than one group / grid of virtual machines. In addition, a given device can support more a virtual machine grouped / activated by grid or more than one virtual machine grouped / included in a grid. In other words, a given device can support a first virtual machine grouped / included in a grid and a second virtual machine grouped / included in a grid, where the two virtual machines grouped / included in the grid are included in two groups / grids of different and independent virtual machines; the two virtual machines grouped / included in the grid and the two groups / grids of virtual machines will be identifiable and accessible in a unique way. Depending on the type of process that is being carried out within a group / grid of given virtual machines, it may be convenient to refer to the nodes that interact within the group / grids of given virtual machines with a local node or a remote node to distinguish between the nodes For example, from the perspective of a given gJVM, the given gJVM can be referred to as the node local, the local gJVM or the local gJVM node; from the perspective of a given gJVM, a different gJVM that interacts with the local node either on the same device or if it is running on another device, can be referred to as a remote node, a remote gJVM or a remote gJVM node. The present invention is directed to transparently allowing the application to run on a set of machines or devices, each of which supports at least one grouped virtual machine node. For example, a multi-line Java® application can be executed in multiple gJVMs, and the application will not need to know or need to know about which machines its lines were dispatched. The group of virtual machines manages and dynamically distributes the lines of the application on the available set of grouped virtual machines. Each group of virtual machines has a single primary node. In Figure 2, the gJVM node 201 is a primary gJVM node, and the gJVM 202-205 nodes are non-primary gJVM nodes. The primary node can have certain obligations or responsibilities that are carried out in the non-primary nodes within the group. For example, the primary node can have a set of objects that define the environment and application context for the application, such as for file access and class loading (class path) by the group of virtual machines. The primary nodes and non-primary nodes can be initiated in a slightly different manner, thereby providing an indication to a given clusterable virtual machine that it must act as a primary node or as a non-primary node. For example, a virtual machine that can be grouped in a Java® environment can be started with the following exemplary start command: java [-main-clusterName] [mainClass] The "java" command can instantly start a clustable virtual machine, that is, start the execution of a given copy of a clustered virtual machine. The "-main" parameter indicates a particular instance of a gJVM to act as a primary gJVM node within a gJVM group that is identified by the "-cluster-Name" parameter; when a particular instant of a gJVM acts as a non-primary gJVM node, the instant start command will not include the "-main" parameter. The "mainClass" parameter specifies the main program to be executed by the gJVM. In this way, the modules of programs and programming systems comprising a primary node and a non-primary node can be copies of one another, being therefore the programs and programming systems or software essentially similar, that is, that a primary node and a non-primary node can be called persons or clones, although a primary node and a non-primary node can exhibit different behavior because a primary node experiences a slightly different instantaneous start process than a non-primary node. Since a primary node and non-primary nodes can simply be independent cases of a clusterable virtual machine, where the primary node and the non-primary nodes simply operate according to two different modes of operation, for example, being initialized differently, a primary node can delegate or transfer its responsibilities to a non-primary node to allow the primary node to interrupt maintenance or for other purposes after the system has been started.

Virtual Grid-Enabled Machine Referring now to Figure 3A, a block diagram illustrates the components and / or information that can be used to improve a virtual machine as a grouped / grid-enabled virtual machine according to an implementation of the present invention. Figure 3A describes the gJVM node 300 representing a single clusterable virtual machine, as any of the nodes 201-205 in Figure 2. Although not shown, the gJVM node 300 comprises other components and information to perform tasks in a manner similar to a typical JVM; in other words, the gJVM node 300 can be considered as a typical JVM that has been improved to include the functionality of the present invention. Although the gJVM node 300 is shown as having multiple types of tables, one skilled in the art will understand that different types of information and different information formats can be administered by a given clustable virtual machine node to effect the functionality of the present invention. . The P2P communication unit 302 allows each gJVM to communicate with any other gJVM in a person-to-person manner, particularly to communicate a functioning information of gJVM to another gJVM. For example, a gJVM can communicate its CPU load factor, its memory factor, and its communication queue load factors to other gJVMs so that the virtual machine group can balance its total load in a distributed way. . A unique ID of gJVM 304 is a data value representing the unique identifier of the virtual machine that has been assigned to a particular gJVM within a group of gJVM since it is identified by the group name of gJVM 306. The environment of application / context parameters 308 defines several values and information that may be necessary during the lifetime of the gJVM 300 for Obtain additional information from your runtime environment and to interact with your runtime environment. For example, each gJVM may need to know the IP address of gJVM and port values of the primary gJVM 310 in which the primary gJVM is configured to communicate with the primary gJVM. Each grouped virtual machine has an execution status, for example, stopped, started, started, and stopped. When a new node with a group of virtual machines is being instantaneously initiated, that is to say, added to the plurality of virtual machines already within the group of virtual machines, the information about its existence is disseminated through the group of virtual machines; when a particular node within the group of virtual machines is being stopped, that is, removed from the rest of the plurality of virtual machines within the group of virtual machines, which can occur without stopping the entire group of virtual machines, information about the Detention of the particular mode is disseminated through the group of virtual machines. In the example shown in Figure 3A, it was assumed that each gJVM node maintains a local copy of a list of gJVM nodes within the gJVM group, which is shown as the gJVM 312 record; The gJVM 300 node can receive updated information near the state of other nodes, which is it then reflects into the gJVM register 312. In this way, the gJVM register 312 provides a record of gJVM that are known to a gJVM 300 node. The gJVM register 312 contains a list of characteristic values for each known gJVM, such as its Unique ID of gJVM 314, its IP address and port 316, and its execution status 318. Each of the gJVMs inside a group of gJVM can communicate various parameters of workload or use of computational resources among themselves so that can determine where to dispatch lines. After a gJVM has been initiated, you can accept work from your gJVM group; when it stops, it moves its lines and associated objects to another gJVM. In contrast to a typical virtual machine, the present invention provides a clustered virtual machine in which objects move between gJVM nodes, thereby allowing a line and its associated objects to move when a case of a virtual machine is being stopped. groupable In a typical prior art system, remote objects are addressed via a combination of an IP address, a TCP / IP port nr, and an object identifier reference; the invocation references of the remote method (RMI) or Common Object Request Switch Architecture (CORBA) also refer to containing other size information relatively large In contrast to a typical virtual machine in which short classes can be used in a typical RMI or CORBA implementation, the present invention provides references to objects so that access to the objects is managed transparently within the time environment of execution of gJVM without short classes, as explained in more detail later. To support moving objects within the present invention, the objects are associated with a group of objects, that is, logically contained within a group of objects. As long as the object exists, its association with a group of particular objects ensures that the group of objects will continue to exist. In other words, a group of objects continues to exist as long as it has at least one object. When all the objects in a group of objects have been collected from the garbage, then the group of objects will be collected from the garbage as well. Groups of objects can be removed between grouped virtual machines. An accessible group of objects exists only on a single clustered virtual machine; access to a group of objects can be restricted while the group of objects is in a migratory state between grouped virtual machines. As a result, each clustered virtual machine has information about the location of a group of objects within the group of virtual machines.

In the example shown in FIG. 3A, the object group register 320 contains a list of group IDs of objects that are known to the gJVM 300 and other associated information to locate those groups of objects within the gJVM set of the gJVM 300, thereby associating each group of known objects with a gJVM that is known by the gJVM 300. For example, a particular group of objects is represented by the object group ID 322, the gJVM node on which the group of objects was assigned to the group ID of objects 322 is identified by the GJVM ID 324, and the migratory status of the group of objects assigned to the ID of the object group 322 is identified by the migration status value 326, which may be one of a set of constant values, each of which represents a different possible migratory status. To provide transparent access and provide the mobility of an object within a group of virtual machines, the internal virtual machine's handling towards the object, ie the reference of the object contains a compact set of information elements that provides the location and Access to the object but does not specify the location of the object. For example, the following Java® structure can be used to specify handling on an object in a Java® environment: Struct ObjectHandle. { Int objectGroupID; // Object group ID Unique Byte [] objectID; // Unique object ID of the object} The ObjectHandle that was specified in the example provided above allows an application that is running within the gJVM group to access the corresponding object anywhere within the gJVM group. By knowing the identifier of the unique object group of a group of objects, any gJVM node can locate the group of objects identified within the group of gJVM; for example, if the group of objects is managed in a table or another type of data store that associates the identifier of the group of objects with an identifier of gJVM, then the gJVM node in which the object resides can be determined. Using other information about the way in which the gJVM node is addressed or accessed, the unique identifier of gJVM can be used to communicate with the gJVM node in which the object resides; for example, if the identifier of gJVM is administered in a table or another type of data store that associates the identifier of gJVM with an IP address and a port number, for example, as shown in the gJVM 312 registry, then the appropriate group of objects can be accessed over the appropriate gJVM node in some way. Although a given gJVM node can be identified by a IP address and a port number, this information is not contained directly within the reference of an object, thus allowing the object to move transparently between gJVM nodes. By knowing the unique identifier of the object so that the object is accessed, then the appropriate object can be accessed within the group of objects on the appropriate gJVM node in some way. Information about the location of groups of objects can be provided by a single JVM object to which all gJVM nodes within the gJVM group can access to query the association between an object group identifier and the gJVM node that is hosting the group of objects. In the example shown in FIGURE 3A, the gJVM node 300 contains local information provided by the object group register 320; for example, the gJVM node 300 can retrieve or receive updates to the object group register 320 from another gJVM node, for example, the primary gJVM node, thereby allowing the gJVM 300 node to perform fast and efficient local queries. Objects and their object groups are created within the stacks of a local gJVM node when necessary. An object can be referenced locally until a reference of the object of the scope of the line is passed, at which point the object will be transparently accessed as a remote object, thus allowing other lines to potentially run on other machines to access them. In one embodiment, groups of objects are preferably created in local stacks of lines of a gJVM node; alternatively, groups of objects can be created within other types of stacks within a pooled virtual machine. Each new line is provided with a new local stack of lines when the line is built; A line can acquire local batteries of additional lines when necessary. A local stack of lines provides high performance because: most accesses to most objects are local to a particular line, objects can be easily discarded-collected; and a stack lock is not required to satisfy object allocations. A local stack of lines is typically implemented as an object of a configurable size to which a particular line has access. To satisfy a typical small object assignment, the local line stack is split at one end to free up the required space. If the local stack of lines is not large enough to satisfy an assignment, the remainder of the local stack of lines is discharged and replaced by a new local stack of lines. Large object assignments can bypass the local stack mechanism of lines and can be met directly from a stack largest within the virtual machine. FIGURE 3A discloses a single stack 328 within node gJVM 300; line 328 is associated with two local stacks of lines 330 and 332, whereby it is illustrated that a line can have a one-to-many association with multiple-line local stacks. The local stack of lines 330 is shown as having a group of objects 334 and the group of objects 336, which contain objects that are not shown in the figure; the local stack of lines 332 is shown as having the group of objects 338, which itself contains the objects 340-342. The information to manage a line is stored inside an object, and this object is also stored within a group of objects. Similarly, the stack structure of lines is managed as an object. FIGURE 3A describes the line management object 344 and the stack structure object 343 for managing that information. In this way, the exemplary data related to a line is stored within a group of objects. If a line moves from a gJVM node to another gJVM node, the sample data moves as part of the process of moving a group of objects. The line code itself does not need to be stored in a group of objects; If the code is not present within the memory, it is available from the class files when necessary. A new group of objects is also created when it is built a new line; An association is created between the group of objects and the newly constructed line, which has a unique line identifier. The line identifiers are unique through a set or group; each pooled virtual machine has a unique virtual machine identifier, thereby allowing the unique line identifiers to be preferably based on a combination of the unique identifier of the virtual machine and a line identifier that is unique within a given virtual machine. Groups of additional objects can be added to a line when necessary. In the example shown in FIGURE 3A, the local object group management table 350 contains a list of groups of objects that are managed within the gJVM 300 node, that is, the groups of objects that are stored within the node gJVM 300, together with other associated information to manage those groups of objects within the gJVM 300 node. For example, a group of particular objects represented by a row in the table, which contains the group ID of objects 352, the indicator 354 for the local stack of lines containing the particular group of objects and the line identifier 356 that is associated with the group of objects; if groups of objects are created alternately within other types of stacks within a pooled virtual machine, then it would be managed different information within the local object group management table 350. As mentioned above, a group of objects can continue to exist as long as they have at least one object; even if the line that was responsible for creating an object ended, the object could have been referenced by another line that still requires its existence, thus requiring that the group of objects in which the object is located continue to exist. Alternatively, the global master object group 360 can be maintained within a gJVM node. When a line ends, all the remaining objects that are contained in its group of associated objects (or groups of associated objects) that are still referenced from other lines, for example, objects 362-368, are moved in groups of global master objects . The group of global master objects will contain all the objects that are globally referenced within the group of gJVM even if the line that originated them has ended, thus allowing the administration of fewer groups of objects.

Movement of the Group of Objects within a Group / Grid of Virtual Machines With reference now to FIGURES 3B-3D, a set of block diagrams illustrates the transfer of groups of objects between grouped virtual machines of according to the present invention. FIGURES 3B-3D describe a set of gJVM nodes within a group of virtual machines over a period of time; FIGURE 3B describes a point in time that is earlier than the point in time that is described in FIGURE 3C, which is earlier than the point in time described in FIGURE 3D. In a manner similar to FIGURE 3A, FIGURE 3B shows the gJVM node 300 which contains the object groups 334, 336 and 338. In addition, the gJVM node 370 contains the object group 372, and the gJVM node 380 contains the group objects 382. As noted above, a group of objects can continue to exist as long as they have at least one object, even if the line that was initially associated with the group of objects ended. FIGURE 3C describes the same gJVM nodes and some groups of objects as FIGURE 3B. However, FIGURE 3C differs from FIGURE 3B in that object group 338 has been transferred from node gJVM 300 to node gJVM 380; for example, the transfer may have occurred in response to the completion of the line that was associated with the group of objects 338, such as line 328 shown in FIGURE 3A. As also noted above, a group of objects can continue to exist as long as they have at least one object, even if the grouped virtual machine that has built the group of objects has been stopped or terminated. The FIGURE 3D describes a final point in time with some of the same gJVM nodes and groups of objects as FIGURE 3C. However, FIGURE 3D differs from FIGURE 3C in that the object groups 334 and 336 have been transferred from the gJVM 300 node to the gJVM node 370. For example, the transfer may have occurred in response to the termination of the gJVM 300 node that it supported groups of objects 334 and 336; when a given gJVM is interrupted, the batteries and / or the other groups of objects in the given gJVM can be transferred to another machine, and the information in the gJVM nodes through the group of virtual machines will be updated with the location of the groups of objects. Garbage collection can also be done within a group or group of virtual machines. In a typical Java® virtual machine, garbage collection is done with a mark and sweep or clean method. In the mark-and-sweep method, garbage collection is invoked either explicitly by an application or automatically when an application tries to allocate an object but memory utilization makes the assignment operation of the object difficult or not possible . The virtual machine goes through all the objects, marks them, then sweeps or cleans all the lines and statistics (global data) to mark again all the objects that can be traversed. The virtual machine pauses all the lines and then searches through the data structures of each line stack structure, so it marks all the objects that are referential by any line, possibly on a per application application basis. All objects that are not marked as referential are then destroyed or removed, thus freeing the virtual machine's memory to assign it to an object. Most objects are typically objects that are accessed only by a line. With the set or group of virtual machines of the present invention as an object can be referred remotely; When an object is referred remotely, it is marked as such. In one mode, a gJVM node can have a separate devil that runs at a low priority and that periodically traverses the system to perform remote garbage collection processing. Each object may have a remote garbage collection bit that is used in a method of marking and sweeping or cleaning the remote garbage collection devil. If an object that has been remotely referred to is not already referenced within the gJVM node in which it was built, then the remote garbage collection devil strives to determine if the reference of the remote object still requires the existence of the object. The little devil can send a request message to other gJVM nodes to ask if a A particular object that may be ready to be released within the local GJVM is still being referred by a remote GJVM; those requests can be grouped for multiple objects so that the reference groups can be verified efficiently. If no remote gJVM node reports that a particular object is still being remotely referenced, then the remote garbage collection devil in the local gJVM node can initiate the removal of the objects, the remote garbage collection devil can remove any indication that the object is / were remotely referred, thus allowing the object to be removed later during the normal / local garbage collection process.

Initialization of the Primary Virtual Machine Activated by Grid With reference now to FIGURE 4, a flow chart illustrates a process for initializing a primary gJVM according to an embodiment of the present invention. The process begins when the node of the primary clustered virtual machine is initialized (step 402), for example, through the use of the instant start command that was described above. The name of the gJVM set or group registered in such a way that allows applications to search for available gJVM groups and avoid collisions name with other sets or groups of gJVM (step 404). The primary gJVM node has any environment parameters or context parameters that are to be employed by the newly initiated gJVM set (step 406) and stores information in such a way that it is available to all nodes in the gJVM set. The primary copy of the object group record within the primary gJVM node is initialized (step 408), which is subsequently available for dissemination as copies to non-primary gJVM nodes, such as the object group record 320 shown in FIGURE 3A. The primary copy of the gJVM record within the primary gJVM node is also initialized (step 410), which is also available later for dissemination as copies to non-primary gJVM nodes, such as the gJVM 312 record shown in FIGURE 3A, thus concluding the process.

Assigning or Registering Unique IDs for Virtual Machine Nodes Activated by Grid With reference now to FIGURE 5A, a flow chart illustrates a process in a primary gJVM to assign a unique identifier of gJVM to a non-primary gJVM that is being initialized. The process begins when the primary gJVM receives the request for a non-primary gJVM from a unique identifier of gJVM (step 502). The primary gJVM generates the unique identifier of gJVM (step 504) and adds the newly generated gJVM identifier to the gJVM record (step 506). The primary gJVM sets or sets the operating status of the non-primary gJVM in the gJVM register as a value of the initial state (step 508), and then the primary gJVM responds to the requesting non-primary gJVM by sending a message containing the identifier single newly generated gJVM (step 510). The primary gJVM then issues a message containing the updated gJVM record to all non-primary gJVM nodes (step 512), thereby concluding the process. Referring now to FIGURE 5B, a flowchart illustrates an alternative process in a primary gJVM to assign a unique identifier of gJVM to a non-primary gJVM that is being initialized. The process begins when the primary gJVM receives a request from a non-primary gJVM to register a unique identifier of gJVM (step 522). In contrast to FIGURE 5A, in which a non-primary gJVM node depends on the primary gJVM node to assign a unique identifier of gJVM, FIGURE 5B shows an exemplary system in which the non-primary gJVM node assigns its own identifier unique from gJVM and then registers its identifier with the primary gJVM node. The non-primary gJVM node can generate its own identifier that is guaranteed to be unique through the execution of an algorithm for that purpose. For example, many devices are manufactured to include a serial number that is read, unalterable, sometimes referred to as a globally unique identifier; since each gJVM node within a group of distributed gJVMs operates on a device, the gJVM node can use an algorithm to create a unique identifier of gJVM, where the algorithm accepts a globally unique identifier of the device as input. The primary gJVM then adds or registers the new identifier of gJVM to the gJVM record (step 524). The primary gJVM sets a working state of the non-primary gJVM in the gJVM record to an initial state value (step 526) and then the primary gJVM responds to the requesting non-primary gJVM by sending a response message with a status value indicating whether or not the registration was successful (step 528). The primary gJVM then issues a message containing the updated gJVM record to all non-primary gJVM nodes (step 530), thereby concluding the process.

Assigning an Object Group ID to a Virtual Machine Node Activated by Non-Primary Grid With reference now to FIGURE 6, a flow chart illustrates a process in a primary gJVM to assign a unique identifier from a group of objects to a non-primary gJVM. The process begins when the primary gJVM receives a requesting a non-primary gJVM and a unique identifier of object group (step 602). The primary gJVM generates the unique identifier of the object group (step 604) and adds the identifier of the newly generated object group to the object group record (step 606). The primary gJVM sets the migration status of the group of objects in the object group record to an initial state value (step 608), and then the primary gJVM responds to the non-primary gJVM by requesting, by sending a message containing the identifier unique from the newly generated group of objects (step 610). The primary gJVM then issues a message containing the updated object group record to all non-primary gJVM nodes (step 612), thereby concluding the process. Alternatively, in contrast to FIGURE 6, in which a non-primary gJVM node depends on the primary gJVM node to assign a unique identifier to the group of objects, an alternative process may be employed in which the non-primary gJVM node assign its own unique identifier to the object group and then register this identifier of the newly generated object group with the primary gJVM node. The non-primary gJVM node can generate its own identifier of the group of objects that is guaranteed to be unique through the execution of an algorithm for that purpose, for example, in a manner similar to that described above with respect to FIGURE 5B .

Provide Specific Information of the Group or Set to Virtual Machine Nodes Activated by Non-Primary Grid With reference now to FIGURE 7, a flow chart illustrates a process in a primary gJVM to provide information about the group or set gJVM to a non-primary gJVM . The process begins when the primary gJVM receives a non-primary gJVM request for information specific to the group or set, such as the current gJVM record, the current object group record, or the group's environment / context parameters (step 702). ). The primary gJVM responds to the requesting non-primary gJVM by sending a message containing the requested information (step 704), thus concluding the process. In this way, a non-primary gJVM node can obtain information from a primary gJVM node, assuming that an implementation of the present invention has a set or group of gJVM in which a primary gJVM node manages the group-specific information in favor of the primary gJVM node.

Change of the State of Operation of the Node of Virtual Machine Activated by Non-Primary Grid With reference now to FIGURE 8, a flow diagram illustrates a process in a primary gJVM to change a state of operation or execution of a non-primary gJVM.

The process begins when the primary gJVM receives a request from a non-primary gJVM to change its operational or execution status (step 802). The primary gJVM updates the gJVM record with the requested operating state (step 804) and responds to the requesting non-primary gJVM with an acknowledge message or acknowledgment (step 806). The primary gJVM then transmits a message containing the updated gJVM record to all non-primary gJVM nodes (step 808), thereby concluding the process.

Changing the Migration Status of the Group of Objects by a Virtual Machine Node Activated by Non-Primary Grid With reference now to FIGURE 9, a flow diagram illustrates a process in a primary gJVM to change a migration status of a group of objects . The process begins when the primary gJVM receives a request from a non-primary gJVM to change a migration status of a group of objects (step 902). The primary gJVM updates the object group record with the requested migration status (step 904) and responds to the requesting non-primary gJVM with an acknowledge message or acknowledgment (step 906). The primary gJVM then transmits a message containing the updated object group record to all non-primary gJVM nodes (step 908), thus concluding the process.

Initialization of the Virtual Machine Node Activated by Non-Primary Grid Referring now to Figure 10, a flow chart illustrates a process for initializing a non-primary gJVM node according to one embodiment of the present invention. The process begins when the non-primary pooled virtual machine node is initialized (step 1002), for example, through the use of the instant start command that was described above. The group name of gJVM is obtained, for example, from the instantaneous start command (step 1004), and a query operation is performed using the group name of gJVM (step 1006), for example, to obtain the parameters of network of a globally available database for initiating communication with the primary gJVM node by the identified gJVM group (step 1008). The non-primary gJVM node requests and receives a unique identifier of gJVM from the primary gJVM node (step 1010), for example, as shown in Figure 5A or Figure 5B. The non-primary gJVM node obtains any information across the group, such as environment parameters or context parameters that are used by the gJVM group (step 1012), for example, as shown in Figure 7. The node of non-primary gJVM also requests and receives from the primary gJVM node the record of gJVM (step 1014) and the record of the group of objects (step 1016), for example, as shown in Figure 7. Although steps 1010-1016 are illustrated as being implemented from In a synchronized manner, the steps can be performed asynchronously in a variety of ways. Since the non-primary gJVM node has completed its initialization, the non-primary gJVM node sends to the primary gJVM node a request to change its operating status from a value indicating that it is in an initial state to a value indicating that it is in an operational or execution state (step 1018). Assuming that the request was successfully executed, the non-primary gJVM node receives an acknowledgment from the primary gJVM node (step 1020), thereby concluding the process. While Figure 10 illustrates an initialization process in a non-primary gJVM node, Figures 5A-9 illustrate processes by which a primary gJVM node performs tasks such as those requested by non-primary gJVM nodes to centrally manage information in the half of the gJVM group as a whole. The remaining Figures describe processes through which non-primary gJVM nodes manage groups of objects and lines within a gJVM group; in other words, the remaining Figures illustrate processes from the perspective of a non-primary gJVM node.

However, it should be noted that a primary gJVM node executes similar processes with respect to the administration of its groups of objects and lines; In those cases in which a Figure illustrates a step in a process in which information is transferred to or received from a primary gJVM node, it should be understood that the primary gJVM node will execute a similar step, except that the primary gJVM node will be able to place information directly in specific group tables or databases, such as the gJVM record or object group record, without having to coordinate the steps with itself, that is, the primary gJVM node.

Construction of the Line in the Virtual Machine Node Activated by Grid With reference now to Figure 11, a flow chart illustrates a process on a grouped virtual machine during which a line is constructed. The process begins when a local gJVM receives a request to build a line (step 1102), for example, through an appropriate API call by an application that is running under the control of the pooled virtual machine, although it is possible that The local gJVM performs a similar process on its own initiative while controlling the execution of the applications on the virtual machine. The local gJVM node, which in some cases can be assumed is a non-primary gJVM, sends a request to the primary gJVM for a unique identifier of the group of objects and then receive this (step 1104). The local gJVM constructs the line (step 1106), which may involve the creation of several line administration objects and the updating of the different line administration tables. A unique line identifier is generated and assigned to the newly constructed line (step 1108). The local gJVM then allocates a local group of lines (step 1110) and creates or demarcates a group of objects within the local group of lines (step 1112), which, depending on the implementation, preferably stores the related objects along the line. The newly created object group identifier is associated with the newly constructed line (step 1114), for example, by updating the appropriate administration tables. The local gJVM then sends a request to the primary gJVM to change the migration status of the group of objects of a value indicating an initial state, which was set by the primary gJVM when the new identifier of the group of objects was requested, to a value indicating a steady state (step 1116). The local gJVM then receives a migration status recognition of the primary gJVM (step 1118). The local gJVM then returns a response for the construction of the line, which may contain the identifier of the line and another information related to the line, to the requesting application (step 1120), thus concluding the process.

Destruction of the Line in the Virtual Machine Node Activated by Grid With reference now to Figure 12, a flow chart illustrates a process in a pooled virtual machine during which a line is destroyed. The process begins when a local gJVM receives a request to destroy a line (step 1202), through an appropriate API call of an application that is running under the control of the pooled virtual machine, although a similar process may occur when The local GJVM decides to destroy a line on its own initiative, for example, due to several termination conditions. Assuming that the groups of objects that are associated with the termination line have external / remote / external references to the objects within themselves, then the groups of objects need to be preserved, even though the line that was originally the reason for creating the objects Groups of objects are ending or are being destroyed now. Accordingly, the local gJVM dissociates the terminal line identifier of each associated object group in an appropriate manner (step 1204), which may include updating several line management tables and administration tables of object groups (step 1206). If necessary, depending on the methods of allocating memory in the local gJVM, it may be necessary to move the groups of objects from the local groups of lines to general groups within the local gJVM (step 1208). It can often be the case that the completion of a line results in almost all of its objects being collected from the garbage; in an alternative mode, objects that remain because they are remotely referenced can be removed to a group of global master objects. The line is then destroyed (step 1210), for example, by destroying the management objects related to the line that were used to control the line. An answer for the line destruction operation is then returned to the requesting application (step 1212), thus concluding the process.

Assignment of Objects in a Virtual Machine Node Activated by Grid With reference now to Figure 13, a flow chart illustrates a process on a pooled virtual machine during which an object is constructed. The process begins when the local gJVM node receives a request to construct an object (step 1302) for example, through an appropriate API call by an application that is running under control of the clustered virtual machine, although a similar process may occur when the local gJVM decides to create an object on its own initiative. The line identifier of the requesting line is determined (step 1304), and the information of the group of objects for a group of objects that is associated with the requesting line is retrieved (step 1306). The local gJVM then allocates an object in one of the object groups of the requesting line (step 1308) and an object identifier is generated by the newly assigned object and assigned to the object (step 1310). An object reference / manipulation is created for the newly created object (step 1312), which may contain the identifier of the group of objects and the identifier of the object, depending on the manner in which the references of the object are implemented. The reference / manipulation of the object is then returned to the requesting line (step 1314), thus concluding the process.

Reference to the Object in a Virtual Machine Node Enabled by Grid With reference now to Figure 14, a flow chart illustrates a process on a pooled virtual machine to handle access to objects. The process begins with the local gJVM intercepting an attempt to access or reference an object via an object manipulation (step 1402). The local gJVM retrieves the identifier from the object group of the object handler (step 1404) and determines whether the identified group of objects is managed locally or remotely (step 1406), for example, by consulting a management table of object groups. If the object is stored locally, then the local gJVM obtains the indicator for the appropriate local group of lines (step 1408) and accesses the object in the local group of lines using the identifier of the object (step 1410). If the object is stored remotely, then the local gJVM obtains the identifier of the remote gJVM node from the group of objects in which the object is located (step 1412). The IP address and port ID of the remote gJVM is retrieved (step 1414), for example, from the local copy of the gJVM record. The local gJVM then sends a request to access the object to the remote gJVM (step 1416), thus concluding the process.

Migration of the Group of Objects from the Virtual Machine Node Activated by Grid With respect now to FIGURE 15, a flow diagram illustrates a process on a local clustered virtual machine to migrate a group of objects to a remote clustered virtual machine. The process begins when the local gJVM node prepares to migrate a group of objects from a local gJVM node to a remote gJVM node (step 1502), which may involve sending a request message to the remote gJVM to migrate a group of objects. This preparation to migrate a group of objects can occur as a result of several conditions, which are described in more detail later. For example, as described with respect to FIGURE 19, before stopping a gJVM node, any group of objects within the gJVM node will migrate to other gJVM nodes with the gJVM group. The local gJVM sends a request to the primary gJVM to change the migration status of the group of objects that migrate from stable to migrant (step 1504), after which the local gJVM receives a migration status recognition from the gJVM primary (step 1506). The local gJVM flattens or puts in a series each object in the group of migrating objects (step 1508) and pushes the flattened or serial objects from the local gJVM to the remote gJVM in some way so that the object remains associated with the group of objects (step 1510), after which the local gJVM receives an acknowledgment from the remote gJVM (step 1512). The local gJVM then destroys the group of objects and / or a group within the local gJVM for the group of objects that has just been moved (step 1514) by simultaneously cleaning or updating the entry of the group of objects in the table of the group of local objects together with any other table entry or database that needs to be cleaned or updated within the local gJVM node (step 1516) because the group of objects is now located within a different gJVM node, thus concluding the process.

Migration of the Group of Objects to the Virtual Machine Activated by Grid With reference now to FIGURE 16, a flow diagram illustrates a process on a local clustered virtual machine to accept the migration of a group of objects from a remote clustered virtual machine. The process shown in FIGURE 16 should be seen as complementary to the process shown in FIGURE 15; The local gJVM and the remote gJVM in FIGURE 15 are the remote gJVM and the local gJVM in FIGURE 16, respectively, reversing their roles. The process begins when the local gJVM receives a request to migrate a group of objects from the remote gJVM to the local gJVM (step 1602), after which the local gJVM assigns a local set of lines or another appropriate type of set ( step 1604) and receive the flattened or serial objects in the object group of the remote gJVM (step 1606). The local gJVM reads or inflates the objects to the chosen location within the local gJVM (step 1608) and associates a group of received objects with a line (step 1610), if necessary, for example, if a line migrated together with the group of objects. The local gJVM then performs the appropriate administrative tasks to manage the newly received group of objects to create an object group entry in the local object group table (step 1612). The local gJVM then sends a request to the primary gJVM to change the migration status of a group of migrant migrant objects to stable (step 1614), after which the local gJVM receives a migration status acknowledgment from the primary gJVM (step 1616). The local gJVM then sends an acknowledgment message to the remote gJVM indicating the conclusion of the group migration of objects (step 1618), thus concluding the process.

Migration of the Virtual Machine Line Activated by Grid Referring now to FIGURE 17, a flow chart illustrates a process on a local clustered virtual machine to migrate a line to a remote clustered virtual machine. The process begins when the local gJVM node prepares to migrate a local gJVM node line to a remote gJVM node (step 1702), which involves sending a request message to the remote gJVM to migrate the line. This preparation to migrate a line can occur as a result of several conditions, which are described in more detail later. The gJVM local pushes the management information of the local gJVM line to the remote gJVM (step 1704); the line management information may comprise information in the administration tables of the local line within the local gJVM node, after which the local gJVM receives an acknowledgment from the remote gJVM (step 1706). The local gJVM then updates the local line administration tables when necessary to reflect the fact that the line has been moved to a different gJVM node (step 1708), thus concluding the process.

Migration of the Line to the Virtual Machine Activated by Grid With reference now to FIGURE 18, a flow chart illustrates a process on a local clustered virtual machine to accept the migration of a line from a remote clustered virtual machine. The process shown in FIGURE 18 should be seen as complementary -to the process shown in FIGURE 17; The local gJVM and the remote gJVM in FIGURE 17 are the remote gJVM and the local gJVM of FIGURE 18, respectively, reversing their roles. The process begins when the local gJVM receives a request to migrate the remote gJVM line to the local gJVM (step 1802), after which the local gJVM receives the administration information of the line for the line of the remote gJVM (step 1804). The local gJVM then performs the appropriate administrative tasks to manage the newly received line, to update the local line administration tables (step 1806). The local gJVM then sends an acknowledgment message to the remote gJVM indicating the conclusion of the migration of the line (step 1808), thus concluding the process.

Interruption of the Virtual Machine Activated by Grid Referring now to FIGURE 19, a flow chart illustrates a process on a local clustered virtual machine to perform an interrupt operation on a clustered virtual machine. The process begins with the determination that the local gJVM needs to perform an interrupt operation (step 1902). The interrupt operation can be the result of a determination within the local gJVM node to terminate itself for a variety of reasons and alternatively, the gJVM node interrupt determination can be controlled by the primary gJVM node, by an administrative utility, by an administrative order or by some other mechanism. The local gJVM node sends a request to the primary gJVM node to change the local gJVM node operating status of a value indicating a status of operation to a value indicating a stopped state (step 1904), after which the local gJVM node receives a recognition message from the primary gJVM (step 1906). The local gJVM then begins to migrate all its lines to other gJVM nodes (step 1908) by also migrating all its object groups to other gJVM nodes at the same time (step 1910). As discussed in more detail below, a gJVM node can perform the migration operations according to information about the performance characteristics of other gJVM nodes within the gJVM group. The local gJVM node then sends a request to the primary gJVM node to change the local gJVM operating status of a value indicating a stop status to a value indicating a stopped state (step 1912), after which the The local gJVM node receives an acknowledgment message from the primary gJVM (step 1914), thus concluding the process. As mentioned above, a primary node can delegate or transfer its responsibilities to a nonprimary node to allow the primary node to be interrupted for maintenance or for other purposes after the system has booted. If a primary node starts an interruption process, the primary node selects a non-primary node to act as the newly delegated primary node, possibly through a mechanism of request / response. In this way, the primary node performs additional operations that are not performed by a non-primary node during the period of time that the primary node is in the stop state. After the delegation operation, the newly delegated primary node can transmit its new identity as the primary node for the group of virtual machines to the other non-primary nodes within the group of virtual machines, which will update its information data structures in consequence.

RECOVERY OF OPERATING INFORMATION BY THE Grid-Activated Virtual Machine With reference now to FIGURE 20, a flowchart illustrates a process on a local clustered virtual machine to collect load or operation information from a remote clustered virtual machine. The process shown in FIGURE 20 performs an operation with respect to all known remote gJVM nodes in an iterative fashion. Consequently, the process begins with the local gJVM node obtaining the information of the local copy of the gJVM record about the next remote gJVM node that has not yet been processed within the iterative circuit (step 2002). The local gJVM then sends a request message to the remote gJVM node identified by its load information (step 2004) after which the local gJVM receives a response message containing the load information of the remote gJVM node (step 2006); the information may be stored within a local table or database for further analysis, for example, using the process that is described with respect to FIGURE 22 below. The local gJVM node then checks if there are some unprocessed gJVM nodes within the local gJVM record (step 2008). If so, then the process branches back to step 2002 to process another remote gJVM node; if there is no unprocessed gJVM node, then the process ends.

Collecting Performance Information by the Virtual Machine Activated by Grid Referring now to FIGURE 21, a flow chart illustrates a process on a local clustered virtual machine to respond to a request from a virtual machine grouped by load information or current operation in the local clustered virtual machine. The process shown in FIGURE 21 should be complementary to the process shown in FIGURE 20; the local gJVM and the remote gJVM in the FIGURE 20 is the remote gJVM and the local gJVM in FIGURE 21, respectively, reversing their roles. The process begins when the local gJVM receives a request message of the load information on the local gJVM and / or the local device (step 2102). For example, charging information can include values that indicate the use of the CPU, memory utilization, other physical components of computing or hardware, programs and programming or software systems, or information on the use of computational resources by the data processing device over which the node local gJVM is operating, information on the use of computational resources for resources within or controlled by the gJVM, and other information. The local gJVM then sends a response message containing the requested loading information (step 2104), thus concluding the process.

Load Balancing Operation Between Virtual Machine Nodes Activated by Grid With reference now to FIGURE 22, a flow chart illustrates a process on a local clustered virtual machine to determine the migration of lines and / or object groups of the virtual machine grouped local to a remote clustered virtual machine according to the loading or operation information. The process begins when the local gJVM node determines to initiate a load balancing operation (step 2202), if appropriate, the local gJVM node obtains or verifies its own load information (step 2204). The local gJVM also obtains load information from other gJVM nodes within the gJVM group (step 2206), for example, using the processes described above with respect to FIGURE 20 and FIGURE 21, although the load information of the other gJVM nodes may be collected only after a determination has been made to initiate the equilibrium operation of cargo. The load balancing operation can be performed to ensure that the workload produced by the execution of several applications within the group is distributed through the gJVM group. The load balancing operation may be the result of a determination within the local gJVM node to initiate a load balancing operation according to an algorithm that may be employed by all the gJVM nodes within a gJVM group; alternatively, the determination to perform the load balancing operation may be controlled by the primary gJVM node, by an administrative utility, by an administrative order, or by some other mechanism. For example, the local gJVM node can perform the load balancing operation after it has built a line and is ready to dispatch the line; alternatively, to save computational resources, the operation of charging fluid can be effected periodically, for example, after each tenth newly constructed line. The local gJVM node then begins to evaluate its load information to verify whether or not some resources on the local gJVM node have exceeded a configurable threshold value, for example, according to what is indicated within the parameters of the specific context of the group. In an example shown in FIGURE 22, two evaluations are made; The number of evaluations that were made may depend on the load balancing algorithm, the available load information, or some other factor. A determination is made to see whether or not the load value of the CPU for the local gJVM node exceeds a CPU load threshold value (step 2208); if not, then the process branches to step 2214. If the CPU load value for the local gJVM node exceeds a configurable CPU load threshold value, then the local gJVM node selects the remote gJVM node with the available CPU resources (step 2210), for example, by analyzing the load information that was previously collected from the remote gJVM nodes with respect to the configurable load threshold values. The local gJVM node then begins a migration operation to move lines from the local gJVM node to one or more selected remote gJVM nodes (step 2212), for example, using the processes described above with respect to FIGURE 17 and FIGURE 18. Then a determination is made to see whether or not the load value of the memory for the local gJVM node exceeds a memory load threshold value (step 2214); If not, then the process concludes. If the memory load value for the local gJVM node exceeds a configurable memory load threshold value, then the local gJVM node selects a remote gJVM node with available memory resources (step 2216), for example, by analyzing the load information that was previously collected from the remote gJVM nodes with respect to the configurable load threshold values. The local gJVM node then begins a migration operation to move groups of objects from the local gJVM node to one or more selected remote gJVM nodes (step 2218), for example, using the processes described above with respect to FIG. 16 and FIGURE 16, thus concluding the process.

Multiple Line Request on Logical Virtual Machine With reference now to Figure 23, a block diagram describes the execution of a single application image encompassing multiple grid-activated virtual machines in a single logical virtual machine on multiple devices. The machines 2302-2306 support the logical virtual machine 2308 and the logical virtual machine 2310. The logical virtual machine 2308 includes only a single node that is represented by the gJVM node primary 2312, which could have been invoked through a command-line interface that specified "GRILL_B" as the group name for the logical virtual machine 2308. The 2308 logical virtual machine is supported on a single device, that is, machine 2306. In contrast, logical virtual machine 2310 includes multiple gJVM nodes 2314-2320 that are supported by multiple devices, i.e. machines 2302-2306; machine 2302 expects to be supported concurrently with two nodes of gJVM 2314 and 2320. Virtual machine 2314-2320 interoperates with a single logical virtual machine. In this example, virtual machines 2314-2320 are implemented using Java® technology; consequently, virtual machines 2314-2320 can be described as Java® virtual machines. Since virtual machines 2314-2320 have built-in functionality to interoperate in the manner of a grid such as a logical virtual machine, virtual machines 2314-2320 can be described as grid-enabled Java® virtual machines (gJVM), each of which is a node within a logic gJVM 2310. Each of the gJVM nodes 2314-2320 could have been invoked through a command line interface that specified "GRID_A" as the group name for the logic gJVM 2310. nodes 2316-2320 are non-primary nodes; gJVM 2314 was designated as the primary node at the beginning, although you can delegate your state as a primary node to another node within the logical gJVM 2310 at a later point in time. In this example, nodes 2314-2320 are unique cases of the same gJVM application program. Using the methods described above, the nodes of gJVM 2316-2320 are recorded in the group / grid of nodes which is managed by the primary gJVM stream node 2314; remote references to objects and coordination between gJVM nodes are provided through communication links gJVM-gJVM (person to person) that are gJVM nodes capable of being established. With the present invention, the multiple gJVM nodes interoperate as a logical gJVM so that a program in the application starting at the gJVM node can be subsequently executed in such a way as to encompass multiple gJVM nodes. In the example in Figure 23, an application including the main line 2322 has been started on the node of gJVM 2318, and one of its secondary line 2324 is also executed on the node of gJVM 2318. In addition, the secondary lines 2326- 2332 of the same application are executed on the gJVM nodes 2314 and 2316 within the logic gJVM 2310. The present invention allows the nodes 2314-2320 to share the Java® 2334 application workload that is running on the logic gJVM 2310 without requiring the Java® 2334 application to deviate from the model of standard Java® application; in other words, the Java® 2334 application does not require any patented functionality, and the gJVM nodes 2314-2320 do not require patented application agents to act in favor of the Java® 2334 application through multiple gJVMs. With the present invention, gJVM nodes 2314-2320 have incorporated functionality to interoperate in a grid-like manner to execute Java® applications. The groups of objects 2336-2346 are distributed through the logic gJVM 2310. Any given application line can refer to objects that exist in several groups of objects, whether or not the application line or another line within the same application built or assigned to those groups of objects. Accordingly, a given line may refer to an object in a local object group or an object in a remote group of objects, whether or not the group of objects associated with the given line or another line in the local gJVM node or over a remote gJVM node. Yes it's him. In fact, the group of objects may not be associated with any existing line, or the object may be contained in a so-called global object group in the local gJVM node in a remote gJVM node. In the example shown in Figure 23, line 2330 is shown as referring to an object or objects in object groups 2336 and 2346 within the local gJVM node 2314 also referring at the same time to an object or objects in the group of objects 2338 within the remote gJVM node 2316. The advantages of the present invention will be apparent with reference to the detailed description that was provided above. The applications that run on virtual machines can be executed with a grid-like shape on a plurality of virtual machines, thus allowing computational resources such as services similar to compensated utilities to be provided. When the systems and data processing devices are interrupted, the virtual machines that can be grouped in those systems and devices can be stopped; the lines and objects in those systems and devices can migrate to other systems and devices while the group of virtual machines allows any applications to continue to function, either in a set of different systems and devices. It is important to note that although the present invention has been described in the context of a fully functional data processing system, those skilled in the art will appreciate that the processes of the present invention may be distributed in the form of instructions in a readable medium in computer and a variety of other forms, regardless of the particular type of media carriers of signals actually used to carry out the distribution. Examples of computer-readable media include media such as EPROM, ROM, tape, paper, floppy disk, hard disk drive, RAM, CD-ROM and transmission type media such as digital and analog communications links. A method is generally conceived so that it is a sequence consistent with itself of steps leading to a desired result. Those steps require physical manipulations of physical quantities. Usually, but not necessarily, these quantities take the form of electrical or magnetic signals that can be stored, transferred, combined, compared and manipulated in another way. It is convenient sometimes, mainly for reasons of common use, to refer to those signals as bits, values, parameters, points, elements, objects, symbols, characters, terms, numbers or the like. It should be noted, however, that all such similar terms and terms will be associated with the appropriate physical quantities and are simply convenient marks applied to those quantities. The description of the present invention has been presented for purposes of illustration but is not intended to be exhaustive or limiting of the embodiments described. Many modifications and variations will be apparent to those skilled in the art. The modalities were chosen to explain the principles of the invention and its practical applications and to enable others skilled in the art to understand the invention to implement various modalities with various modifications that may be suitable for other contemplated uses.

Claims (33)

1. CLAIMS 1. A method for operating a virtual machine within a data processing system, the method is characterized in that it comprises the steps implemented in the computer of: storing an object in a memory that is managed by a virtual machine that is operating in a device within the data processing system; associating the object with a plurality of objects within a group of objects; associating the group of objects with the virtual machine, where the virtual machine incorporates the functionality to interoperate with other virtual machines in a group of virtual machines, and where each virtual machine in the group of virtual machines acts as a node within the group of machines virtual administer a plurality of groups of objects within each virtual machine of the group of virtual machines; and allow the group of objects to be moved from the virtual machine to a different virtual machine in the group of virtual machines. The method according to claim 1, characterized in that it further comprises: dissociating the group of objects from the virtual machine; move the group of objects to the different virtual machine in the group of virtual machines; and in response to the movement of the group of objects to the different virtual machines, associate the group of objects with the different virtual machines. The method according to claim 1, characterized in that it further comprises: sharing information about the location of a plurality of the group of objects with each virtual machine in the group of virtual machines. The method according to claim 1, characterized in that it further comprises: associating the group of objects and a different group of objects with a line administered by the virtual machine. 5. The method of compliance with the claim 4, characterized in that it further comprises: storing the group of objects and the different group of objects in a local group of lines associated with the line. The method according to claim 4, characterized in that it further comprises: storing the group of objects in a first local group of lines associated with the line; and storing the different group of objects in a second local group of lines associated with the line. 7. The method of compliance with the claim 4, characterized in that it further comprises: dissociating the group of objects from the line; finish the line; and in response to the termination of the line, ~ administer the group of objects without an association between the group of objects and a line managed by the virtual machine. The method according to claim 1, characterized in that it further comprises: creating an object handling for the object that is independent of the location of the object. The method according to claim 8, characterized in that it also comprises: generating a handling of objects for the object; store in the handling of objects a group identifier for the group of objects with each of the associated objects, where the identifier of the group is unique within the group of virtual machines; and storing in the handling of the object an object identifier for the object, where the identifier of the object is unique within the group of objects with which the object is associated. The method according to claim 1, characterized in that it also comprises: creating a reference of the object for the object that be independent of the location of the object and independent of the location of the group of objects with which the object is associated. The method according to claim 1, characterized in that it further comprises: creating a first object reference for the object, while the object is located in the virtual machine; move the group of objects with which the object is associated with the different virtual machine; and create a second object reference for the object while the object is located in a different virtual machine, where the reference to the first object and the reference to the second object are identical. 12. A computer program product in a computer-readable medium for use in a data processing system for operating a virtual machine, the computer program product is characterized in that it comprises: means for storing an object in memory that are managed by a virtual machine that is running on a device within the data processing system; means for associating the object with a plurality of objects within a group of objects; means to associate the group of objects with the virtual machine, where the virtual machine incorporates the functionality to interoperate with other virtual machines in a group of virtual machines, and where each virtual machine in the group of virtual machines acts as a node within the group of virtual machines; means for managing a plurality of groups of objects within each virtual machine of the group of virtual machines; and means for allowing the group of objects to move from the virtual machine to a different virtual machine in the group of virtual machines. 13. The computer program product according to claim 12, characterized in that it further comprises: means for dissociating the group of objects from the virtual machine; means for moving the group of objects to the different virtual machine in the group of virtual machines; and means for associating the group of objects with the different virtual machine in response to the movement of the group of objects towards the different virtual machine. 14. The computer program product according to claim 12, characterized in that it further comprises: means for sharing information about the location of a plurality of groups of objects with each virtual machine in the group of virtual machines. 15. The computer program product according to claim 12, characterized in that it further comprises: means for associating the group of objects and a different group of objects with a line administered by the virtual machine. 16. The computer program product according to claim 15, characterized in that it further comprises: means for storing the group of objects and the different group of objects in a local group of lines associated with the line. 17. The computer program product according to claim 15, characterized in that it further comprises: means for storing the group of objects in a first local group of lines associated with the line; and means for storing the different group of objects in a second local group of lines associated with the line. 18. The computer program product according to claim 15, characterized in that it further comprises: means for dissociating the group of objects from the line; means to finish the line; and means for managing the group of objects without an association between the group of objects and a line managed by the virtual machine in response to the termination of the line. 19. The computer program product according to claim 12, characterized in that it further comprises: means for creating an object handling by the object that is independent of the location of the object. 20. The computer program product according to claim 19, characterized in that it further comprises: means for generating a handling of objects for the object; means for storing in the handling of objects a group identifier for the group of objects with which the object is associated, where the unique group identifier within the group of virtual machines; and means for storing in object handling an object identifier for the object, where the identifier of the object is unique within the group of objects with which the object is associated. 21. The computer program product according to claim 12, characterized in that further comprises: means for creating an object reference for the object that is independent of the location of the object and that is independent of the location of the group of objects with which the object is associated. 22. The computer program product according to claim 12, characterized in that it further comprises: means for creating a first object reference for the object while the object is located in the virtual machine; means to move the group of objects with which the object is associated with the different virtual machine; and means for creating a second object reference for the object while the object is located in the different virtual machine, where the first reference of the object and the second reference of the object are identical. 23. An apparatus in a data processing system for operating a virtual machine, the apparatus is characterized in that it comprises: means for storing an object in memory that is managed by a virtual machine that is operating in a device within the processing system of data; means for associating the object with a plurality of objects within a group of objects; means to associate the group of objects with the virtual machine, where the virtual machine incorporates the functionality to interpolate with other virtual machines in a group of virtual machines and where each virtual machine in the group of virtual machines acts as a node within the group of virtual machines Virtual machines; means for managing a plurality of groups of objects within each virtual machine of the group of virtual machines; and means for allowing the group of objects to be moved from the virtual machine to a different virtual machine in the group of virtual machines. 24. The apparatus according to claim 23, characterized in that it further comprises: means for dissociating the group of objects from the virtual machine; means for moving the group of objects to the different virtual machine in the group of virtual machines; and means for associating the group of objects with the different virtual machine in response to the movement of the group of objects to the different virtual machine. 25. The apparatus according to claim 23, characterized in that it further comprises: means for sharing the information about the location of a plurality of groups of objects with each virtual machine in the group of virtual machines. 26. The apparatus according to claim 23, characterized in that it further comprises: means for associating the group of objects and a different group of objects with a line administered by the virtual machine. 27. The apparatus according to claim 26, characterized in that it further comprises: means for storing the group of objects and the different group of objects in a local group of lines associated with the line. The apparatus according to claim 26, characterized in that it further comprises: means for storing the group of objects in a first local group of lines associated with the line; and means for storing the different group of objects in a second local group of lines associated with the line. 29. The apparatus according to claim 26, characterized by further comprising: means for dissociating the group of objects from the line; means to finish the line; and means for managing the group of objects without any association between the group of objects and a line managed by the virtual machine in response to the termination of the line. 30. The apparatus according to claim 23, characterized in that it further comprises: means for creating an object handling for the object that is independent of the location of the object. 31. The apparatus according to claim 30, characterized in that it further comprises: means for generating a handling of the object for the object; means for storing in the handling of the object a group identifier by the group of objects in which the object is associated, where the group identifier is unique within the group of virtual machines; and means for storing in object handling an object identifier for the object, where the object identifier is unique within the group of objects with which the object is associated. The apparatus according to claim 23, characterized in that it further comprises: means for creating an object reference for the object that is independent of the location of the object and that is independent of the location of the group of objects with which it is associated the object. 33. The apparatus according to claim 23, characterized in that it further comprises: means for creating a first object reference for the object while the object is located in the virtual machine; means for moving the group of objects with which the object is associated with a different virtual machine; and means for creating a second object reference for the object, while the object is located in the different virtual machine, where the first reference to the object and the second reference to the object are identical.