TWI467491B - Method, system, and computer program product for modified computer architecture with coordinated objects - Google Patents

Description

Method, system and computer program product for a modified computer structure using a coordinated object

The present invention relates to computers and other computing machines and information appliances, and more particularly to a modified computer architecture and program structure that enables an application to be interconnected by using a decentralized run time communication link. Multiple computers can be synchronized or simultaneously and can achieve improved performance.

Since the advent of computers and computing, the software of computers has been written to work on a single machine. As shown in Fig. 1, the prior art single machine 1 is constituted by a central processing unit or CPU 2, which is connected to the memory 3 through a bus bar 4. At the same time, the busbar 4 is connected to a plurality of other functional units of the single machine 1, such as a screen 5, a keyboard 6, and a mouse 7.

The functionality of the performance of the machine 1 is limited to the data to be manipulated by the CPU 2 and the results of those manipulations must be moved by the busbar 4. The busbar 4 encounters some problems, including the so-called busbar "column", which is formed by the unit that wants to gain access to the busbar, competing for problems and the like. These problems can be eliminated to some extent by a variety of strategies, including cache memory, but these strategies always increase the management load of the machine 1.

Naturally, there have been many attempts over the years to increase machine performance. One way is to use a symmetric multiprocessor. This prior art approach has been used for so-called "super" computers, the architecture of which is shown in Figure 2. The plurality of CPUs 12 are connected to a common memory 13. Again, communication between the CPU 12 and the memory 13 can cause a bottleneck. Only one application and the entire copy of the application's memory can be spread across the common memory. The single application can be read and written (ie shared) by any memory location in a completely transparent manner.

When some of these machines are interconnected through a network, this can be achieved by using a single application written for a single machine and dividing the required memory resources into many parts. These portions are then scattered between some computers to form the common memory 13 accessible by all CPUs 12. This program relies on isolating or hiding the memory cell from the single execution application. This performance is reduced when a CPU on a machine has to access (through a network) a memory location that is actually on a different machine.

Although supercomputers have been technically successful at achieving high computational speeds, they are not successful in commercial applications because their inherent complexity makes them very expensive, not only in manufacturing, but also in management. In particular, this single system imaging concept has never been able to operate on commercial (or mass-produced) computers and networks in size. In particular, this single system imaging concept can only be practically applied when it is interconnected on a very fast (and therefore very expensive) computer with very fast (and equally expensive) networks.

Another possibility to increase computer power is through the use of complex machines, which are derived from the prior art concept of decentralized computing, the architecture of which is shown in Figure 3. In this known configuration, a single application (Ap) is drawn into multiple distributed jobs by its author (or by other programmers familiar with the application), thereby executing on, for example, three machines, the third The example n in the figure is an integer 3. The purpose is that each machine M1,..., M3 will perform a different one-third of the entire application, and the purpose is that the loads applied to different machines are approximately equal. The machines communicate over a network 14, which can be provided in a variety of forms, such as a communications link, an intra-area network, an area external network, and a regional network. Basically, the operating speed of such a network 14 will be slower than that of the bus 4 in each individual machine M1, M2, ..., Mn.

Decentralized operations encounter some drawbacks. First of all, it is very difficult to draw the application and it must be done manually. Second, the transfer of data, partial results, results, and the like on the network 14 is a management load. Third, there is a need to draw points to make it very difficult to use more machines to expand, because applications that have been drawn into three, for example, cannot work well on four machines. Fourth, if one of these machines must be de-energized, the overall performance of the overall system will be substantially reduced.

Another prior art configuration is to perform network operations through "clusters", the architecture of which is shown in Figure 4. In this way, the entire application is loaded onto each machine M1, M2,..., Mn. Each machine is associated with a shared repository but does not communicate directly with other machines. Although each machine executes the same application, each machine performs a different job and uses only its own memory. This is similar to some windows, each of which sells train tickets to the public. This method can be operated and expanded, and its main disadvantage is that it is difficult to manage the network.

In computer languages such as JAVA and MICROSOFT.NET, programmers use two main types of structures. In the JAVA language, it is known as objects and classes. More generally, they can be called assets. Each time an object (or other asset) is generated, there is an initialization routine that is initialized to an object (eg, "<init>"). Similarly, each time this category is loaded, there is a category initialization routine called "<clinit>". Other languages use different terms, but use a similar concept. In either case, however, there is no equivalent "clear" or delete instance to delete when an object or category (or other asset) is no longer needed. Instead, this "clearing" occurs unobtrusively in a background mode.

Furthermore, in any computer environment, it is necessary to obtain and release a lock to use such an object, category, asset, resource or structure to prevent different parts of the application from attempting to use the same at the same time. Object, category, asset, resource, or structure. In the JAVA environment, this is synchronization. Synchronization is more commonly referred to as the exclusive use of an object, category, resource, structure, or other asset to avoid contention between computers or machines. In JAVA, this is achieved by the "monitor entry" and "monitoring leave" commands or examples. Other languages use different terms, but use a similar concept.

Unfortunately, the computer system, architecture and operation schemes that are not used do not provide a computing environment and method. One application can operate on any number of computers at the same time. The environment and operation scheme can ensure the above-mentioned memory management and initialization. The cleanup and synchronization routines work in a consistent and coordinated manner on all of these computing machines.

The present invention discloses a computing environment in which an application can simultaneously work on a plurality of computers. In such an environment, it is advantageous to ensure that the asset initialization, cleanup, and synchronization scenarios described above operate in a consistent and coordinated manner across all of the machines.

In accordance with a first aspect of the present invention, a multiple computer system is disclosed having at least one application, each of which is programmed to operate on only a single computer, but on a plurality of computers interconnected by a communication network Simultaneous execution, wherein different parts of the application are executed substantially simultaneously on different parts of the computer, and for each part a similar plurality of substantially identical objects are generated, each of which is in the corresponding computer And each having a substantially identical name, wherein the initial content of each of the objects of the same name is substantially the same, wherein all of the same objects are no longer required to be referenced by each of the plurality of computers The corresponding objects are deleted together, and the system includes a locking means that can be applied to all of the computers, and any computer that wants to utilize one of the named objects is obtained by the locking means. An authorization lock, which allows the use, and it prevents all other computers from using the object of their corresponding name until the authorization lock is abandoned.

According to a second aspect of the present invention, a method is disclosed for simultaneously executing at least one application on a plurality of computers, each of which is programmed to operate on only a single computer, the computers being interconnected by a communication network, The method comprises the steps of: (i) executing different portions of the application on different computers of the computers, and generating a plurality of substantially identical objects for each of the portions, each of the phases being Corresponding to the computer, each having a substantially identical name, (ii) generating substantially the same initial content for each of the same named objects, (iii) when all of the plurality of computers no longer need to refer to them correspondingly All of the same items are deleted together, and (iv) any such computer that wants to utilize one of the named items is required to obtain an authorized lock, which allows for use and which prevents all other computers Use them to have named objects until the authorization lock is abandoned.

In accordance with a third aspect of the present invention, a multiple computer system is disclosed having at least one application, each of which is programmed to operate on only a single computer, but at the same time in a plurality of computers interconnected by a communication network Executing, wherein different parts of the application are executed substantially simultaneously on different computers in the computers, wherein each computer has a separate local memory that can only be accessed by corresponding portions of the application And wherein a plurality of substantially identical objects are generated for each of the portions, each of which is on the corresponding computer.

According to a fourth aspect of the present invention, there is disclosed a plurality of computers interconnected by a communication link, each having a separate local memory and substantially simultaneously operating at least one different portion of the application, each of which Each is written to work on a single computer, and each local memory is accessed only by the corresponding portion of the application.

According to a fifth aspect of the present invention, a method is disclosed for simultaneously executing at least one application on a plurality of computers, each of which is programmed to operate on only a single computer, the computers being interconnected by a communication network, And each having a separate local memory, the method comprising the steps of: (i) executing different portions of the application on different computers in the computers, and generating substantially the same plurality for each of the portions Objects, each on the corresponding computer, and each of which can only be accessed by a corresponding portion of the application.

In accordance with a sixth aspect of the present invention, a method is disclosed for loading an application to be written to a single computer to each of the computers, the computers being interconnected by a communication link, And different parts of the applications can be executed substantially simultaneously on different computers, each computer having a separate local memory that can only be accessed by a corresponding portion of the application, the method being included The relevant part of the application is loaded before, during or after the loading, and the steps to fix the application before being executed.

According to a seventh aspect of the present invention, a method is disclosed for simultaneously operating at least one application on all of a plurality of computers interconnected via a communication link, each of which is programmed to operate on only a single computer, each Each of the computers has at least one minimum predetermined local memory capacity. The different parts of the application are executed substantially simultaneously on different computers in the computers, and the local memory of each computer can only be used by the application. Accessed by the corresponding portion, the method comprises the steps of: (i) initially providing each local memory under substantially the same conditions, and (ii) satisfying each of the application portions from the corresponding local memory All memory generated and written by the copies, and (iii) all of the memory is transferred to each of the computers via the communication links, which occurs in all of the remaining computers in the plurality of computers Above the local, by which an update data transmission delay is received by the content of the local memory used by each computer, that is, it remains substantially the same.

According to an eighth aspect of the present invention, a method is disclosed for compiling or modifying an application that is written to work on only a single computer, but simultaneously on a plurality of computers interconnected by a communication link Executing, the different parts of the application are executed simultaneously on different computers in the computer, each having a separate local memory, which can only be accessed by the corresponding part of the application, the method The method comprises the steps of: (i) detecting a shared memory record using one of the computers, (ii) listing all of the shared memory records, and providing one of each listed memory record. Name tags, (iii) detect those instructions written to any of the listed memory records, or manipulate their contents, and (iv) start after each detected write or manipulate command An update delivery modality that conveys the rewritten or manipulated content and name tags of each of the rewritten or manipulated table column memory records to the remaining computers.

According to a ninth aspect of the present invention, a multi-thread processing computer operation is disclosed in which an individual thread written as a single application operating on only a single computer is simultaneously on a different computer in a plurality of computers Processing, each having only one independent local memory accessed by the corresponding thread, and each interconnected by a communication link, the improvement comprising transmitting a change in the content of the local memory through the communication link, It is physically associated with the computer and processes each thread of the local memory of each other computer.

The invention further discloses a computing environment in which an application can simultaneously work on a plurality of computers. In this environment, it is advantageous in that the above-described initialization example can be operated in a consistent manner on all machines.

According to a tenth aspect of the present invention, a multiple computer system is disclosed having at least one application, each of which is programmed to operate on only a single computer, but at the same time in a plurality of computers interconnected by a communication network Executing, wherein different portions of the applications are executed substantially simultaneously on different computers in the computers, and for each of the portions, a plurality of substantially identical objects are generated, each of which is in the corresponding computer Up, and each having substantially the same name, and the initial content of each of the objects of the same name is substantially the same.

According to an eleventh aspect of the present invention, a plurality of computers interconnected via a communication link are disclosed, and at least one application is simultaneously operated, each of which is written to operate only on a single computer, wherein each of the computers Essentially executing a different part of the application at the same time, each of the computers operating on the application portion only generates objects in the local memory of each of the computers, which are used by each of the computers. The contents of the local memory are substantially similar, but are not the same in each instance, and each of the computers has a decentralized update means to be distributed to all other such computer objects produced by the computer.

According to a twelfth aspect of the present invention, a method is disclosed for simultaneously executing at least one application on a plurality of computers, each of which is programmed to operate on only a single computer, the computers being interconnected by a communication network The method comprises the steps of: (i) executing different portions of the application on different computers in the computers, and generating a plurality of substantially identical objects for each of the portions, each of the corresponding computers And each has a substantially identical name, and (ii) produces substantially the same initial content of the same named object.

According to a thirteenth aspect of the present invention, there is disclosed a method of compiling or modifying an application which is written to operate on only a single computer for different computers in a plurality of computers interconnected by a communication link The different portions are executed substantially simultaneously, the method comprising the steps of: (i) detecting an instruction to generate an object using one of the computers, and (ii) initiating an initialization after each of the detected objects generates an instruction. For example, the initialization example transfers each generated object to the remaining computers.

According to a fourteenth aspect of the present invention, there is disclosed a multi-thread processing computer operation in which individual threads of a single application written to work on only a single computer are simultaneously on different computers in a plurality of computers Ground processing, each having one independent memory accessed by only the corresponding thread, and each interconnected by a communication link, the improvement comprising transmitting the object generated in the local memory through the communication link It is physically connected to the computer and processes each thread of the local memory of each other computer.

According to a fifteenth aspect of the present invention, a method is disclosed to ensure consistency initialization of an application, which is written to work on only a single computer, but the different parts thereof are transmitted through a communication network. Executing simultaneously on different computers in the interconnected plurality of computers, the method comprises the steps of: (i) scrutinizing or analyzing the application during loading, before or after, to detect each of the definitions of an initialization instance The program steps, and (ii) correct the initialization routine to ensure consistent operation of all of the computers.

The invention further discloses a computing environment in which an application can simultaneously work on a plurality of computers. In this environment, the advantage is that it ensures that the "cleanup" (or deletion or finalization) works in a consistent manner across all machines. The purpose of the finalization of consistency is the origin of the invention.

According to a sixteenth aspect of the present invention, there is disclosed a multiple computer system having at least one application, each of which is programmed to operate on only a single computer, but at the same time in a plurality of sections interconnected by a communication network Executed on a computer, wherein different portions of the applications are executed substantially simultaneously on different computers in the computer, and a plurality of substantially identical objects are generated for each of the portions, each of which corresponds to the corresponding On the computer, and each having substantially the same name, and each of the same items is collectively deleted when each of the plurality of computers no longer needs to refer to their corresponding objects.

According to a seventeenth aspect of the present invention, a plurality of computers interconnected via a communication link are disclosed, and at least one application is simultaneously operated, each of which is programmed to operate only on a single computer, wherein each of the computers Essentially executing a different part of the application at the same time, each of the computers may need or no longer need to refer to an object in the local memory only when operating the application portion thereof. On the computer, the content of the local memory used by each computer is basically similar, but it is not the same in each instance, and each part of the computers has a finalized example, which is only when When each of the plurality of computers no longer needs to refer to their corresponding objects, an unreferenced object is deleted.

According to an eighteenth aspect of the present invention, a method is disclosed for simultaneously executing at least one application on a plurality of computers, each of which is programmed to operate on only a single computer, the computers being interconnected by a communication network The method comprises the steps of: (i) executing different portions of the application on different computers in the computers, and generating a plurality of substantially identical objects for each of the portions, each of the corresponding computers Up, and each having a substantially identical name, and (ii) all of the same objects are collectively deleted when all of the plurality of computers no longer need to refer to their corresponding objects.

According to a nineteenth aspect of the present invention, a method is disclosed to ensure consistency of consistency of an application, which is written to work only on a single computer, but different parts thereof are transmitted through a communication network. Simultaneous execution of multiple computers in a plurality of computers interconnected, the method comprising the steps of: (i) scrutinizing the application during, during or after loading to detect a definition of a finalization The program steps, and (ii) correct the finalization to ensure that the objects corresponding to all of the computers are deleted together only when each of the computers no longer needs to refer to their corresponding objects.

According to a twentieth aspect of the present invention, a method for processing a computer job by a multi-thread is disclosed, wherein an individual thread system written as a single application on only a single computer is being processed at the same time, each of which is processed Each thread is processed on a different computer in a plurality of computers interconnected by a communication link, and the objects in the local memory physically associated with the computer are processed in each of the other computers. The local memory has corresponding objects, and the improvement includes collectively deleting all of the corresponding objects when each of the plurality of computers no longer needs to refer to their corresponding objects.

According to a twenty first aspect of the present invention, there is disclosed a multiple computer system having at least one application, each of which is programmed to operate only on a single computer, but in a plurality of sections interconnected by a communication network Simultaneous execution on a computer, wherein different portions of the application are executed substantially simultaneously on different computers in the computers, and a plurality of substantially identical objects are generated for each portion, each of which is in the corresponding computer And each has a substantially identical name, and the system includes a locking mechanism or locking means that can be applied to all of the computers, wherein any computer that wants to utilize one of the named objects can be locked by the locking mechanism An authorization lock is obtained which allows the use and prevents all other computers from using their corresponding named objects until the authorization lock is abandoned.

According to a twenty-second aspect of the present invention, a plurality of computers interconnected via a communication link are disclosed, and at least one application is simultaneously operated, each of which is written to operate only on a single computer, wherein each of the The computer essentially executes a different part of the application at the same time. Each computer uses an object in the local memory only when operating its application part, and the entity is located in each of the computers. The contents of the local memory used by each computer are substantially similar, but are not the same in each instance, and each of the computers has a lock-up instance and a release lock instance that allow The local object is used by only one computer, and each of the remaining plurality of computers is locked out of use of their corresponding objects.

According to a twenty-third aspect of the present invention, a method is disclosed for simultaneously executing at least one application on a plurality of computers, each of which is written to operate only on a single computer, the computers being mutually connected by a communication network The method comprises the steps of: (i) executing different portions of the application on different computers in the computers, and generating a plurality of substantially identical objects for each of the portions, each of which is Corresponding to computers, each having a substantially identical name, and (ii) any such computer that wishes to utilize one of the named objects requires an authorization lock that allows for use and prevents all other The computer uses their corresponding name object until the authorization lock is abandoned.

According to a twenty-fourth aspect of the present invention, a method is disclosed to ensure consistency synchronization of an application, which is written to work only on a single computer, but different parts of which are to be transmitted through a communication The network interconnects the plurality of computers simultaneously on different computers. The method includes the following steps: (i) scrutinizing the application after being loaded, before or after to detect each definition-synchronization example The program steps, and (ii) correct the synchronization example to ensure that an object is used by only one computer and that all other computers are simultaneously using their corresponding objects.

According to a twenty-fifth aspect of the present invention, a method for processing a computer job by a multi-thread is disclosed, wherein an individual thread system written as a single application on only a single computer is being processed at the same time, each of which is Each thread is processed on a different computer in a plurality of computers interconnected by a communication link, and the object physically associated with the computer's local memory is processed in each of the other computers. The local memory has corresponding objects, and the improvement includes allowing only one of the computers to use one object and preventing all remaining computers from using their corresponding objects at the same time.

According to a twenty-sixth aspect of the present invention, a computer program product is disclosed which includes a set of program instructions stored in a storage medium and operable to allow a plurality of computers to perform the above method.

According to a twenty-seventh aspect of the present invention, a decentralized execution time and a decentralized execution time system are disclosed for constructing communication between a plurality of computers, computing machines, or information appliances.

According to a twenty-eighth aspect of the present invention, a modifier, a modifier, and a modifier are disclosed to modify an application that is written once on a single computer or computing machine to simultaneously Executed on a networked computer or computing machine. Decentralized execution time and decentralized execution time systems are used to form communication between a plurality of computers, computing machines, or information appliances.

According to a twenty-ninth aspect of the present invention, a computer program and a computer program product are disclosed, which are written to work only on a single computer, but the product includes a set of program instructions stored in a storage medium and available To allow the plurality of computers to execute the above examples, operations, and methods.

Appendix reference

While the specification provides a complete and detailed description of several specific embodiments of the present invention, the invention may be understood, and may be practiced without reference to other materials, which include Appendices A, B, C, and D, in which Exemplary actual programs or code segments that implement various aspects of the specific embodiments described. Although the description of the various aspects of the present invention includes the appendix, the drawings, and the scope of the patent application, it can be understood that Appendix A is mainly related to the field, Appendix B is mainly about initialization, and Appendix C is mainly about finalization, and Appendix D is mainly about synchronization. More specifically, the accompanying appendices provide: Appendix A1-A10 illustrates example code to illustrate a particular embodiment of the invention with respect to a field.

Appendix B1 is an exemplary typical code segment for initializing <clinit> from an uncorrected class, and Appendix B2 is the equivalent of initializing the <clinit> instruction for a modified class. Appendix B3 is a typical code fragment for initializing an <init> instruction from an uncorrected object. Appendix B4 is an equivalent to initializing the <init> instruction for a modified object. In addition, Appendix B5 is another option for the code of Appendix B2 for an uncorrected class initialization instruction, and Appendix B6 is another option for the code of Appendix B4 to initialize the <init> instruction for an uncorrected object. Furthermore, the accessory B7 is an exemplary computer program source code of the InitClient, which queries an "initialization server" for the initialization state of the related category or object. Appendix B8 is the computer program source code of InitServer, which receives an initialization status query of the InitClient and returns the corresponding status in response. Similarly, Appendix B9 is the computer program source code for the sample application in the previous/after examples of Appendix B1-B6.

It is to be understood that the description provided herein is for the purpose of the present invention, and the description of the subject matter of the present invention, and the use of other headings and sub-headings in this description are intended to be an aid to the reader and are not intended to limit the scope of the invention in any way.

The present invention discloses a modified computer architecture that enables an application to be executed concurrently on a plurality of computers in a manner that overcomes the limitations of the conventional architecture, systems, methods, and computer programs.

In one aspect, the memory shared in each computer can be updated with corrections and/or overwrites, so all memory read requests can be satisfied locally. An instruction to rewrite or manipulate memory in memory may be recognized during or after the program is loaded, but before or after execution of the relevant portion of the code. The insertion of additional instructions into the code (or other made corrections) can result in an update of the equivalent memory location on all computers. The invention is not limited to JAVA languages or virtual machines, and exemplary embodiments are described in relation to JAVA languages and standards. In another aspect, initialization of the JAVA language category and objects (or other assets) is provided, so all memory locations of all computers are initialized in the same manner. In another aspect, the finalization of JAVA language categories and objects is also provided, so finalization only occurs when the last category or object that appears on all machines is no longer needed. In yet another aspect, synchronization is provided such that instructions that cause the application to acquire (or release) a lock (synchronization) of a particular asset can be identified. Additional instructions (or other executed code modifications) are inserted to generate a modified synchronization pattern for all computer updates.

The invention also discloses a computing environment and an arithmetic method in which an application works simultaneously on a plurality of computers. In such an environment, it is advantageous to ensure that the initialization, cleanup, and synchronization routines described above operate in a consistent and coordinated manner across all of the machines. These memory copies, objects, or other asset initialization, finalization, and synchronization can be used and applied in a variety of computing and information processing environments, respectively. Moreover, they are preferably implemented and applied in any combination to provide synergy for multiple computer processing, such as network-based distributed computing.

Because each of the architectures, systems, programs, methods, and computer programs of the present invention (eg, memory management and copying, initialization, finalization, and synchronization) can be applied independently, they will be described first without reference. To other aspects. However, it is important to understand that the purposes, categories, and other assets mentioned in this description are generated or initialized, usually before the finalization of these purposes, categories, or other assets.

As will be further appreciated from the further description provided herein, one of the features of the present invention is to make it a shared application or application code, and its executable version (with similar corrections), which is tied to The plurality of computers or machines M1...Mn are executed simultaneously or synchronously. In the many details that follow, the invention is implemented by executing the same application on each machine (for example, Microsoft Word or Adobe Photoshop CS2), but correcting the executable of the application on each machine. Codes are necessary so that each execution of an "instance" ("replica") on each machine can be coordinated with its local work on any particular machine and with individual examples on other machines, so that they are all It can work together in a consistent, coordinated, and reconciled manner and makes it a common example of the application (ie, meta-application).

In accordance with a particular embodiment of the present invention, a single application code 50 (sometimes informally referred to as an application or application) can simultaneously be interconnected by a communication network or other communication link or path 53 of some machines M1, M2. ... Mn works simultaneously. The communication network or path can be any electronic signaling, data or digital communication network or path, preferably a relatively low speed communication path, such as a network connection on the Internet, or any shared network. Configuration, known or available as the date or application, extension and improvement.

By way of example (but not limitation), an application code or program 50 can be a single application on such machines, such as Microsoft Word, relative to different applications on each machine, such as Microsoft Word on machine M1, machine M2 On top of Microsoft PowerPoint, and Netscape Navigator on machine M3. Therefore, the term "a" application code or program, and a "shared" application code or program are used to attempt and capture the situation in which all machines M1, ..., Mn operate or execute the same program or code. And not a different (and irrelevant) program. In other words, copies or copies of identical or substantially identical application code are loaded into each interoperable and connected machine or computer. Because the characteristics of each machine or computer can vary, the application code 50 can be modified prior to loading, during the loading process, and with some restrictions after the loading process to provide the code on each machine. Customization or correction. Some dissimilarities between the programs may allow for as long as the interoperability, persistence, and coordination requirements described herein are maintained. It will be understood later that each machine M1, M2, ... Mn operating the same application code 50, in each machine M1, M2, ... Mn, and therefore all machines M1, M2, ... Mn has the same or substantially the same application code 50 and will typically have machine specific corrections.

Similarly, each machine M1, M2, ... Mn has the same (or substantially the same or similar) modifier 51 on each machine M1, M2, ..., Mn (in some embodiments) Implemented as a decentralized computing time or DRT 71 operation, so all machines M1, M2, ... Mn have the same (or substantially the same or similar) modifiers 51 for each required correction. For example, different corrections for Memory management and copying, initialization, finalization, and/or synchronization are all required (although all of these types of corrections are not required for all embodiments).

In addition, at each time the machine code 50 (or its associated portion) is loaded on each machine M1, M2, ..., Mn or at any time prior to its execution, each application code 50 has been based on the same rules. The corresponding modifier 51 corrects (or substantially the same rule, since the micro-optimization changes are allowed within each of the correctors 51/1, 51/2.,,, 51/n). When individual corrections are required on any particular machine, such as machine M2, to affect the memory management, initialization, finalization, and/or synchronization of the machine, then each machine can actually be based on a number of individual modifiers. (eg 51/2-M (M2 memory management modifier), 51/2-I (eg M2 initialization modifier), 51/2-F (eg M2 finalization modifier) and / or 51/2-S (such as the M2 synchronization modifier)) has and is modified; or can be combined with any other one or more of these modifiers to become a modifier of the computer or machine combination. In at least some embodiments, the plurality of steps or clusters of a computer or machine are performed in an organized, consistent, and coordinated manner while performing the required steps to identify the required corrections and performing the actual corrections. The coordination will be very efficient. These corrections can be performed in accordance with various aspects of the present invention by the decentralized execution time means 71 described in detail below. In a similar manner, those skilled in the art will be able to understand the structure of the decentralized execution time, the decentralized execution time system, and the decentralized execution time means, as provided herein. Methodological aspects, since the descriptions herein are specific to memory management, initialization, finalization, and/or synchronization, any modifications required for an application or application code can be performed independently or in combination. To achieve any required memory management, initialization, finalization, and/or synchronization on any particular machine or across a plurality of machines M1, M2, ..., Mn.

Using the provided specific reference for any memory management modifier, the memory management modifier 51-M or DRT 71-M or other code correction means component of the entire modifier or decentralized execution time means is responsible for each A memory structure and content is created or copied on individual machines M1, M2, ... Mn, allowing the plurality of machines to operate with each other. In some embodiments, the duplicated memory structure will be the same. In other embodiments, the memory structure will have the same portion and other different portions, and in other embodiments. The memory structures may or may not be the same.

Referring to any initialization modifiers that may be present, these initialization modifiers 51-I or DRT 71-I or other code correction means components of the overall modifier or decentralized execution time means are responsible for modifying the application code 50, so that it can be executed Initialization routines or other initialization operations, such as categories and object initialization methods or instances in JAVA language and virtual machine environments, which span the complex machine M1 in a coordinated, harmonized, and consistent manner. M2, ... Mn.

Referring to possible finalization modifiers, these finalization modifiers 51-F or DRT 71-F or other code modification means are responsible for modifying the application code 50, so the code can perform finalization removal, or other memory modification. Recycling, deleting, or finalizing operations, such as the final method or example of categories and objects in a JAVA language and virtual machine environment, which spans the complex machine M1 in a coordinated, harmonized, and consistent manner. , M2, ... Mn.

Furthermore, with reference to any synchronization modifiers that may be present, these synchronization modifiers 51-S or DRT 71-S or other code modification means are responsible for ensuring that the modified application is executed on one or more machines. A portion of 50 (eg, a thread or process) specifically utilizes (eg, by a synchronization instance or similar or equivalent mutual exclusion operator or job) a particular local asset, such as an object 50X-50Z or Class 50A, there is no other difference on the machines M2...Mn and it is possible to perform a partial uniquely immediate or simultaneous use of equivalent corresponding assets corresponding to similar in their local memory.

These structures and programs, when applied in combination, when needed, maintain a computing environment in which memory locations, address ranges, objects, categories, assets, resources, or any other procedural or structural nature of any computer or computing environment. The aspects are generated, maintained, manipulated, and revoked or deleted as needed, spanning the complex machine M1, M2...Mn in a complex, coordinated, and consistent manner.

Attention is now directed to the particularities of several aspects of the invention, which may be utilized separately or in any combination.

Memory management and replication

In connection with FIG. 5, in accordance with a preferred embodiment of the present invention, a single application code 50 (sometimes more informally referred to as an application or application) may be through a communication network or other communication link or Some machines M1, M2..., Mn interconnected by path 53 operate simultaneously. By way of example (but not limitation), an application code or program 50 would be a single shared application on the machine, such as Microsfot Word, as opposed to a different application on each machine, such as on machine M1. Microsoft Word, Microsoft PowerPoint on machine M2, and Netscape Navigator on machine M3. Therefore, the terms "a", "single" and "shared" application code or program are used to attempt and capture the situation in which all machines M1, ..., Mn operate or execute the same program or code, and Not a different (and irrelevant) program. In other words, copies or copies of identical or substantially identical application code are loaded into each interoperable and connected machine or computer. Because the characteristics of each machine or computer can vary, the application code 50 can be modified prior to loading, during the loading process, or after the loading process to provide customization or correction of the code on each machine. . Some dissimilarities between the programs may allow for as long as the interoperability, persistence, and coordination requirements described herein are maintained. It will be understood later that each machine M1, M2, ... Mn operating the same application code 50, in each machine M1, M2, ... Mn, and therefore all machines M1, M2, ... Mn has the same or substantially the same application code 50 and will typically have machine specific corrections.

Similarly, each machine M1, M2, ... Mn operates on the same (or substantially the same or similar) modifier 51 on each machine M1, M2, ... Mn, so all machines M1, M2. ,, Mn has the same (or substantially the same or similar) modifier 51, and the modifier of the machine M1 is designated as 51/1, and the modifier of the machine M2 is designated as 51/2 or the like. In addition, the application code 50 on each machine M1, M2, ... Mn is based on the same corrector 51 before or during loading, or before execution, or even after it has been performed. The rules are to correct (or substantially the same rules, because tiny optimization changes are allowed within each modifier 51/1, 51/2, ..., 51/n).

As will be further appreciated from the further description provided herein, one of the features of the present invention is that one of the application code 50 application examples spans all of the complex machines M1, M2, ... , Mn is performed simultaneously. In the many details that follow, the invention is implemented by executing the same application code on each machine (for example, Microsoft Word or Adobe Photoshop CS2), but correcting the application on each machine. The execution code is necessary so that each execution event (or "local illustration") on each machine in the machines M1~Mn can coordinate its local operations with the individual events on each of the other machines. Having each event on each of the plurality of machines work together in a consistent, coordinated, and reconciled manner, thereby making it a common illustration (or event) of the application and the code (ie, super Application (meta-application).

As a result of the above configuration, if each of the machines M1, M2, ..., Mn has an internal memory capacity of 10 MB, the entire memory available for each application code 50 need not be regarded as one that can be expected as the number of machines. Multiply by 10MB, or an increase in the internal memory capacity of all n machines, but still only 10MB. When the internal memory capacity of the machines is different, it is permissible, and then when the internal memory in one machine is smaller than the internal memory capacity of at least one other machine, then the minimum memory of any machine The size of the body can be used as the maximum memory capacity of the machines, when the memory (or a portion thereof) is treated as a "common" memory (ie on each machine M1...Mn) Similar to equal memory) or otherwise used to execute the shared application code.

However, even if the internal memory of each machine is initially treated as a possible limitation of performance, how this will result in improved operation and performance will be more apparent below. Naturally, each machine M1, M2..., Mn has a private (ie "non-shared") internal memory capacity. The private internal memory capacities of the machines M1, M2, ..., Mn are generally approximately equal, but not necessarily equal. It is also preferred to select the size of the internal memory in each machine to achieve the desired level of performance in each machine, and across multiple connected or coupled machines, computers or information appliances M1, M2 ,..., Mn cluster or network. Having described these internal and shared memory considerations, it will be understood from the description provided herein that the memory size that can be shared between machines is not a limitation of the present invention.

It is known from the prior art to operate a single computer or machine (manufactured by one of a plurality of manufacturers and having an operating system operating in one of a plurality of different languages) in a particular language of the application, Generate a virtual machine, as shown in Figure 6. The code, data, and virtual machine configuration or configuration of Figure 6 takes the form of an application code 50 written in the Java language and executed within a Java virtual machine 61. Thus, when the internal language of the application is the Java language, it uses a JAVA virtual machine that is capable of running Java-written code regardless of the machine manufacturer and the internal details of the machine. For further details, please refer to "The JAVA Virtual Machine Specification", 2nd Edition, by Sun Microsystems, Inc., T. Lindholm and F. Yellin, which is incorporated herein by reference.

The conventional technical configuration of Fig. 6 is modified in accordance with a specific embodiment of the present invention, which provides an additional facility, conventionally referred to as "decentralized execution time" or "decentralized execution time system" DRT 71, as shown in Fig. 7. Shown in .

In FIG. 7, the application code 50 is loaded into the Java virtual machine 72 and operates in conjunction with the distributed execution time system 71 via the load program indicated by arrow 75. As used herein, the terms "decentralized execution time" and "decentralized execution time system" are basically synonymous, and by way of illustration (but not limitation), they are generally understood to include library code and processing, which can be supported. Software written in a specific language on a particular platform. In addition, a decentralized execution time system can also include library code and processing that can support software written in a particular language that is executed in a particular distributed computing environment. The execution time system basically handles the details of the interface between the program and the operating system, such as system calls, program startup and termination, and memory management. To illustrate the background, a conventional distributed computing environment (DCE) that does not provide the innovative decentralized execution time or decentralized execution time system 71 required by the present invention is available from the Open Software Foundation. This Distributed Computing Environment (DCE) can take the form of computer-to-computer communication of software executing on such machines, but in many of its limitations, it is not capable of implementing the modification or communication operations of the present invention. Among its many functions and operations, the DRT 71 of the present invention can coordinate specific communications between the plurality of machines M1, M2, ... Mn. Furthermore, the decentralized execution time 71 of the present invention is during the load procedure indicated by arrow 75 of the JAVA application 50 on each of the JAVA virtual machines 72 of the machines JVM #1, JVM #2, ... JVM #n. Start the assignment. The sequence of jobs during loading will be explained below with reference to Figure 9. It will be appreciated from the description provided herein that although many of the examples and descriptions provided herein are provided in relation to the JAVA language and the JAVA virtual machine, the reader can achieve the benefits of a particular example, but the invention is not limited to the JAVA language. Or JAVA virtual machine, or limited to any other language, virtual machine, machine or work environment.

Fig. 8 shows a modification of the configuration of Fig. 5, which utilizes JAVA virtual machines, each of which is illustrated in Fig. 7. It will be appreciated that it again loads the same application code 50 onto each machine M1, M2..Mn. However, the communication between each machine M1, M2, ..., Mn, represented by arrow 83, although physically guided by the machine hardware, is preferably by the individual DRT 71 within each machine. Controlled by /1...71/n. Therefore, in fact, this can be conceptually regarded as 71/1, ... 71/n of the DRT, which communicates with each other through the network or other network link 73, rather than through the machines M1, M2, .. .Mn are themselves direct communication with each other or with each other. In fact, the present invention contemplates and includes such direct communication or a combination of such communications between the machines M1, M2, ..., Mn or DRTs 71/1, 71/2, ... 71/n. The communication provided by the DRT 71 of the present invention is independent in transmission, protocol, and link.

It will be appreciated that under the description herein, the modifier 51 and the distributed execution time 71 will have additional implementations. For example, the modifier 51 can implement or be within a component of the distributed execution time 71, such that the DRT 71 can implement the functions and operations of the modifier 51. In addition, the function and operation of the corrector 51 can be implemented in addition to the structure, software, firmware or other means for implementing the DRT 71. In a specific embodiment, the modifier 51 and the DRT 71 are implemented or written in a single paragraph of the computer code, and the functions of the DRT and the modifier are provided. Therefore, the modifier function and structure may be included in the DRT and be regarded as an optional component. In addition to how it is implemented, the modifier function and structure is responsible for modifying the executable code of the application code program, and the distributed execution time function and structure is responsible for implementing communication between the computers or machines. The communication functions in a particular embodiment are implemented by an intermediate protocol layer within the computer code of the DRT on each machine. For example, the DRT can implement a communication stack in the JAVA language and use the Transmission Control Protocol/Internet Protocol (TCP/IP) to provide communication or conversation between the machines. In fact, how these functions or operations are implemented or divided between structural and/or procedural elements, or between the computer code or data structure of the present invention, is less important than the ones they provide.

However, in the configuration illustrated in Figure 8 (also in Figures 31-32), it provides a plurality of individual computers or machines M1, M2, ... Mn, each of which is transmitted through a communication network 53 or Other communication links are interconnected, and each individual computer or machine has a modifier 51 (see Figure 5) and is released, for example, by the Decentralized Execution Time (DRT) 71 (see Figure 8). And loaded with a shared application code 50. The term shared application is understood to mean an application or application code written to be executed on a single machine and loaded on the computer or machine M1, M2...Mn in whole or in part. Or, as needed, on each of the plurality of sub-sets of the plurality of computers or machines M1, M2...Mn. But somewhat differently, there is a shared application, represented by application code 50, and this single copy or possibly multiple identical copies are modified to produce a modified copy or version of the application or code, each A copy or illustration is prepared to be executed on the plurality of machines. After they are corrected, they are considered to be shared if they perform similar jobs and operate consistently and harmonically. It will be appreciated that a plurality of computers, machines, information appliances, or the like, embodying features of the present invention, may be coupled or coupled to other computers, machines, information appliances, or the like that do not implement the features of the present invention, as desired.

Basically, in at least one embodiment, the modifier 51 or the DRT 71 or other code modification means is responsible for modifying the application code 50, so that it can perform memory manipulation operations, such as memory, in a JAVA language and a virtual machine environment. The PUTSTATIC and PUTFIELD commands are in a coordinated, consistent, and harmonic manner and span between the individual machines M1...Mn of the complex portion. So next in this computing environment, it must ensure that each memory location is manipulated in a consistent manner (relative to the others).

In some embodiments, some or all of the plurality of individual computers or machines may be contained within a single enclosure or enclosure (eg, a so-called blade server, by Hewlett-Packard Development, Intel Corporation, IBM Corporation, and others). Manufactured) either on a single printed circuit board or even in a single wafer or wafer set.

A machine (manufactured by any of a number of manufacturers and having an operating system operating in any of a number of different languages) operable in a particular language of the application code 50, in this case a JAVA language . That is, a JAVA virtual machine 72 is capable of operating the application code 50 in the JAVA language and utilizing a JAVA architecture that is independent of the machine manufacturer and the internal details of the machine.

When implemented in a non-JAVA language or application code environment, the generalized platform, and/or virtual machine, and/or machine, and/or execution time system are capable of operating an application code 50 in the language of the platform. (may include, for example, but not limited to, any one or more of a source code language, a mediation code language, an object code language, a machine code language, and any other code language), and/or a virtual machine, and/or machine, and/or Execute the time system environment and utilize the platform, and/or virtual machine, and/or machine, and/or execution time system, and/or language architecture, regardless of the machine manufacturer and internal details of the machine. It will also be appreciated in the description provided herein that the platform and/or execution time system can include virtual machine and non-virtual machine software and/or firmware architectures, as well as hardware and direct hardware coding applications and implementations.

For a more general combination of virtual machine or abstract machine environments, and for current and future computer and/or computing machines and/or information appliances or processing systems, and which may or may not utilize categories and/or The structure, method, computer program and computer program product of the present invention will still be applicable. Examples of computers and/or computing machines that do not utilize categories and/or objects include, for example, x86 computer architectures manufactured by Intel Corporation and others, SPARC computer architectures manufactured by Sun Microsystems and others, and by IBM Corporation. And the PowerPC computer architecture manufactured by other companies, as well as personal computer products manufactured by Apple Computer and other companies. For these types of computers, computing machines, information appliances, and virtual machines or virtual computing environments that are not implemented using categories or objects, for example, they can be generalized to include basic data types (eg, integer data types). Different, floating point data type, long integer data type, double data type, string data type, symbol data type and Bolling data type), structured data type (such as array and record) Type, or code or data structure of other procedural languages, or other languages and environments, such as functions, indicators, components, modules, structures, references, and collections.

Referring now to Figures 7 and 9, during the loader 75, the application code 50 is being loaded onto each JAVA virtual machine 72, which is modified by the DRT 71. This correction is performed in step 90 of Figure 9, and includes the initial step 91, which preferably scrutinizes or analyzes the code and detects all memory locations addressable by the application code 50, or as needed a subset of all memory locations that can be addressed by the application code 50; for example, such as a name and a no-name memory location, variables (eg, local variables, shared variables, and formal arguments to sub-examples or functions), The range of fields, scratchpads, or any other address space, or address that the application code 50 can access. In some instances such memory locations need to be identified in steps 92 and 93 for subsequent processing. In some embodiments, for further processing of memory locations that require detection of a list, the DRT 71 during the loader 75 generates a series of all memory locations that are thereby identified. In a specific embodiment, the memory locations in the form of JAVA fields are listed by objects and categories, but the memory locations, fields or the like may be listed or organized in any manner as long as they are This program is used in accordance with the structuring and stylization requirements of the system, and the principles of the invention described herein. This detection is optional and is not required in all embodiments of the invention. It may be noted that the DRT can at least partially complete the list of the modifiers 51.

The next stage of the correction procedure (step 92 specified in Figure 9) [Step 92] is to search the entire application code 50 so that when needed, the manipulation or change corresponds to the list generated in step 91. The activity of the value or content of any listed memory location (such as, but not limited to, a JAVA field). Preferably, any one or more of the values or contents of any one or more of the listed memory locations are manipulated or changed so that processing activity is located.

When such a processing activity or job is detected (basically "putstatic" or "putfield" in the JAVA language, or for example a memory specified job, or a memory write job, or a memory manipulation job, or A more general operation that can manipulate or change the value or content of a memory or other addressable area, which can change the value or content of a listed or detected memory location, and then by application code 50 Step 93 is inserted in an "update transfer example" corresponding to the detected memory manipulation job to communicate with all other machines to notify all other machines of the location of the manipulated memory, and the manipulation The value or content of an updated, manipulated, or changed memory location. The inserted "update transfer modality" is preferably a network communication library in the form of a method, function, program or similar sub-routine call, or job to DRT 71. In addition, the "update transfer example" may take a selective form of code blocks (or other online code form) that is inserted into the application code instruction stream at the timing of the manipulation instruction or job corresponding to the detection. , after, before or at other times. Preferably, in a multiplex or parallel processing machine environment (and in some embodiments with or without a operating system), for example, a machine environment can potentially perform multiple or different threads or processes simultaneously or simultaneously. The "update delivery example" can be executed on the same thread or processing or processor, as in the memory manipulation operation detected in step 92. The loader then continues by loading the modified application code 50 on the machine 72 in place of the uncorrected application code 50, as indicated by step 94 of FIG.

Another form of correction during loading is illustrated in Figure 10. The start and list steps 90, 91 and the search step 92 are the same as in FIG. However, in addition to inserting the "update transfer modality" into the application code 50, the memory manipulation operation corresponding to the detection indicated in step 92 is represented, as represented in step 93, wherein the application code of the DRT 50 or the network communication library code 71 is executed on the same thread or processing or processor, as the detected memory manipulation job, performs the update, and an "alarm example" is inserted to correspond to The detected memory in step 103 manipulates the job. The "alarm example" indication, notification, or otherwise may require a different and possibly simultaneous or synchronous execution of a thread or process or processor that is not used to perform the memory manipulation operation (ie, different than manipulation) The memory location or the processor or processor or processor or processor (eg, a different thread or processor or processor) configured to provide different threads or processing to the DRT 71 to perform identification of the memory location of the manipulation The notification, transmission or communication of all other machines, and the value or content of the update, manipulation, or change of the memory location of the manipulation.

Once this correction has occurred during the loading procedure and the modified application code 50 begins to execute, the steps of Figure 11 or Figure 12 occur. Figure 11 (and steps 112, 113, 114 and 115 therein) corresponds to the execution and operation of the modified application code 50 when it is modified according to the procedure disclosed and described in Figure 9. On the other hand, Fig. 12 (steps 112, 113, 125, 127 and 115 therein) discloses therein the execution and operation of the application code 50 corresponding to the correction, when it is corrected according to Fig. 10.

The analysis or scrutiny of the application code 50 may occur prior to loading the application code 50, or during loading of the application code 50, or even after the application code 50 loads the program. It can be similar to an installation, program conversion, translation, or compiler, where the application code can be implemented with additional instructions, and/or can be modified by meaning retention program manipulation, ie, or alternatively by an input code language. Translating into a different code language (for example, translation from a source code language or an intermediate code language to an object code language or a machine code language), and knowing that the term compilation usually or customally contains changes in the code or language, such as From source code or object code, or from one language to another. However, in this example the term "compilation" (and its grammatical equivalents) is not so limited and may include or contain amendments within the same code or language. For example, the compilation and its equivalents can be understood to include both normal compilation (eg, by way of illustration and not limitation, from source code to object code), and compiled from source code to source code, and compiled from object code to object. The code, and any combination of any of them. It may also include a so-called "mediation code language" in the form of "virtual object code".

By way of illustration and not limitation, in one embodiment, analysis or scrutiny of the application code 50 may occur during loading of the application code, such as by the operating system from the hard disk or other storage device or source. The application code is read, copied to memory, and ready to begin execution of the application code. In another embodiment, in a JAVA virtual machine, the analysis or scrutiny can occur during a class loader of the java.lang.ClassLoader loadClass method (eg, java.lang.ClassLoader.loadClass()).

In addition, the analysis or scrutiny of the application code 50 can occur even after the application code loading program, for example, after the operating system has loaded the application code into the memory, or alternatively even in the application code. After the relevant corresponding part has been executed, for example, after the JAVA virtual machine has loaded the application code into the virtual machine, it adopts the "java.lang.ClassLoader.loadClass()" method and selects Execute sexually.

As shown in Fig. 11, a multi-thread processing machine environment 110 exists on each of the machines M1, ... Mn and includes threads 111/1 ... 111/4. The processing and execution of the second thread 111/2 (in this example) causes the thread 111/2 to manipulate a memory location in step 113 by writing to a listed memory location. According to the correction for the application code 50 in steps 90-94 of FIG. 9, the application code 50 is corrected at the location corresponding to the memory location of step 113, so its manipulation, notification or communication step 113 is manipulated. The identification of the memory location and the changed value to other machines M2, ... Mn, through the network 53 or other communication link or path, as shown in step 114. At this stage, the processing of the application code 50 of the thread 111/2 can be changed, in some cases interrupted by executing the inserted "update transfer example" in step 114, and the same thread 111 The identification or change value of the memory location manipulated by the /2 notification or transfer or communication step 113 to all other machines M2, ... Mn, through the network 53 or other communication link or path. At the end of the notification, delivery or communication program 114, the thread 111/2 continues the processing or execution of the application code 50 modified in step 115.

In another configuration, shown in FIG. 12, a multi-thread processing machine environment 110 includes or has threads 111/1, ... 111/3, and a simultaneous or synchronous execution DRT processing environment 120 includes the execution. Thread 121/1, as shown, or optionally a plurality of threads, are executed on each of the machines M1, ... Mn. The processing and execution of the application code 50, as modified by the thread 111/2, results in the memory manipulation operation of step 113, which in this example is written to a listed memory location. According to the corrections made to the application code 50 in steps 90, 91, 92, 103 and 94 in FIG. 9, the application code 50 is corrected corresponding to the position written to the memory location in step 113, so its requirement or In addition, the DRT processing environment 120 is notified to notify or communicate or communicate the identification of the memory location of the manipulation of step 113 and the changed value to other machines M2, . . . Mn, as in steps 125 and 128, and arrow 127. Shown. According to this modification, the thread 111/2 processing and the application code 50 for performing the correction require that one of the DRT processing environments 120 is different and may simultaneously or synchronously execute a thread or process (eg, thread 121/1) to notify step 113. The identified and changed values of the manipulated memory locations are to the machines M2, ... Mn, which pass through the network 53 or other communication links or paths, as indicated by step 125 and arrow 127. In response to the requirements of step 125 and arrow 127, one of the DRT processing environments 120 is different and may simultaneously or synchronously execute the thread or process 121/1 and notify the machines M2 via the network 53 or other communication link or path, .. The value of the identification and change of the memory location manipulated by the Mn step 113 is required by the correction application code 50 executed on the thread 111/2 and the arrow 127 of the step 125.

Step 125 of the thread 111/2 of Fig. 12 can be performed quickly, as compared to step 114 of the thread 111/2 of Fig. 11 explained earlier, because the step 114 of the thread 111/2 must pass through the A relatively slow network 53 (e.g., relatively slow when compared to the internal memory bus 4 of Figure 1 or the shared memory 13 of Figure 2) notification or communication machine M2, ..., Mn step 113 The value of the manipulated memory location is identified and changed, wherein step 125 of thread 111/2 communicates with machine M2.,, Mn through the relatively slow network 53. Rather, step 125 of thread 111/2 requires or otherwise informs one of the DRT processing environments 120 that it is different and possibly simultaneously or synchronously executing thread 121/1 to notify and communicate the manipulation of step 113 via the relatively slow network 53. The identification of the memory location and the changed value to the machine M2, ... Mn, as indicated by arrow 127. Therefore, the thread 111/2 executing step 125 is temporarily interrupted only before the thread 111/2 restarts or continues the processing or execution of the modified application code in step 115. The other threads 121/1 of the DRT processing environment 120 then transmit the identified and changed values of the memory locations manipulated in step 113 to the machine M2 via the relatively slow network 53 or other relatively slow communication link or path. ,...Mn.

The second configuration of Fig. 12 preferably utilizes the processing power of a plurality of threads 111/1...111/3 and 121/1 (generally they are not subjected to equal requirements). Regardless of the configuration used, the identification and changed values of the memory locations manipulated in step 113 are communicated to all other machines M2...Mn on the network 53 or other communication link or path.

This is illustrated in Fig. 13, in which step 114 of FIG. 11 or DRT 71/1 (corresponding to DRT processing environment 120 of Fig. 12) and its thread 12/1 of Fig. 12 (step by Fig. 13) 128 represents), through the network 53 or other communication link or path, the identification and change values of the memory locations manipulated in step 113 of FIG. 11 and FIG. 12 are transmitted to each of the other machines M2. .., Mn. Referring to Fig. 13, each of the other machines M2, ..., Mn performs an action received from the network 53, such as the identification and change of the memory position from the manipulation of step 113 of the machine M1, by the arrow Represented by 135, and write the value received at step 135 to the local memory location corresponding to the identified memory location received at step 135, as shown in step 136.

In the conventional configuration of FIG. 3, the distributed software is used, and the memory of one machine is used as the memory to access the memory of the physical device on the other machine, which is connected by the network. allow. However, because the read and/or write memory accesses the memory of the physical host on another computer, the slow network 14 is required. In these configurations, the memory access causes memory. The substantial delay of the bulk read/write processing operation may be around 10 ⁶ - 10 ⁷ cycles of the central processing unit of the machine, but will eventually depend on various factors, such as the rate and frequency of the network 14 Width and / or delay. Most of this would result in reduced performance of multiple interconnected machines in the prior art configuration of Figure 3.

However, in the present configuration described above in relation to Figure 8, it will be appreciated that all memory locations or data reads can be satisfied locally because of the current values of all (or all of a subset) memory locations. It is stored on the machine that performs the process of generating the request to read the memory.

Similarly, in the present configuration described above in connection with Fig. 8, it will be understood that all memory locations or data writes can be satisfied locally because all (or all of a subset) memory locations are currently present. The values are stored on a machine that performs the process of generating the request for writing to the memory.

Such local memory read and write processing operations performed in accordance with the present invention are substantially satisfied within 10 ² - 10 ³ cycles of the central processing unit. Thus, in practice, memory accesses involving reads will have substantially shorter waits than those shown and described with respect to FIG. In addition, there is actually a substantially shorter wait for memory accesses involving writes than for the configurations shown and described with respect to FIG.

It can be seen that most application software reads memory more often, and less often writes to memory. Therefore, the rate at which the memory is written or rewritten is relatively lower than the rate at which the memory is read. Since the need for memory writing or rewriting is slow, the memory location or field can be continuously updated at a relatively slow rate through a relatively slow and inexpensive commercial network 53. The rate may be relatively slow enough to meet the needs of applications written to memory. The result of this configuration for Figure 8 is better than that shown in Figure 3. It can be appreciated from the description provided herein that when a relatively slow network communication link or path 53 is preferably used because it provides the desired performance and low cost, the present invention Not limited to a relatively slow network connection, and any communication link or path can be used. The invention is not related to transmission, network and communication paths and does not occur depending on the communication between the machine or the DRT. In a specific embodiment, even an email (EMAIL) exchange between the machine or DRT is sufficient for communication.

In another alternative modification described above, the identification of the manipulated memory locations transmitted on the network 53 and the changing of the value pairing, each pairing is substantially for example a single packet, frame or unit. Content to be transmitted, which can be grouped into batches corresponding to the identification of multiple manipulated memory locations and multiple pairs of varying values, and a single packet, frame on the network 53 or other communication link or path Or units to send together. This additional correction further reduces the need to interconnect the communication rates of the network 53 or other communication links or paths of these various machines, as each packet, unit or frame can include multiple identifications and changing value pairs, so only need Send fewer packets, frames, or cells.

It can be appreciated that in an environment where the application code is repeatedly written to a single memory location, the embodiment illustrated in FIG. 11 of FIG. 114 transmits an update and delivers a message to a memory corresponding to each execution. Body manipulation on all machines. In still another alternative modification described above, the DRT thread 121/1 of FIG. 12 does not need to perform one update and transfer operation corresponding to each local memory manipulation job, but can also transmit specific memory manipulation. The job requires less updates and messages, each message containing the last or most recent changed value or content of the manipulated memory location, or only a single update corresponding to the last memory manipulation job can be transmitted and Pass the message. This further improvement may reduce the need for the network 53 or other communication links or paths as only a small number of packets, frames or units need to be transmitted.

It will also be apparent to those skilled in the art from the detailed description provided herein that each DRT 71 is generated when the initial recording or generation of all memory locations (or fields), or any subset thereof, is made. A table, or list, or other data structure for each such recorded memory location on each machine M1,..., Mn has a name or identification in each machine M1,..., Mn is common or similar. However, in individual machines, the local memory location corresponding to a given name or identification (eg, as listed in step 91 of Figure 9) will change over time as each machine can and will typically be based on Its own internal processing stores the changed memory value or content in different memory locations. Therefore, the table, table column or other data structure in each DRT corresponds to a single memory name or identification will usually have a different local memory location, but each shared "memory name" or identification will have the same " The memory value is stored in a different local memory location.

It will also be appreciated by those skilled in the art from the description provided herein that the above-described corrections for loading the application code 50 can be accomplished in a variety of ways or by different means. These means or means include, but are not limited to, at least the following five methods, or variations or combinations of the five, including: (i) recompilation at load time, (ii) by loading prior to loading a precompiled program, (iii) compiled before loading, (iv) an "immediate" compilation, or (v) recompiled after loading (but or performing related or corresponding, for example, in a decentralized environment Before applying the code).

Traditionally the term "compilation" refers to a change in code or language, such as from source code to object code, or from one language to another. It is expressly intended that the term "compilation" (and its grammatical equivalents) as used in this specification is not so limited and may include or contain modifications within the same code or language.

For the basic idea of correcting the memory manipulation operation to coordinate the operation between the plurality of machines M1...Mn, there are several different ways or specific embodiments of the coordination, reconciliation and consistency memory state and manipulation concepts and methods. The program can be carried out or implemented.

In a first embodiment, a particular machine, such as machine M2, loads the asset (eg, category or item), which includes a memory manipulation job, corrects it, and then loads the memory containing the new correction. Corrected objects (or categories or other assets or resources) are loaded onto each of the other machines M1, M3, ... Mn (either sequentially or simultaneously, or according to any other order, exemplification or procedure). Please note that there may be one or more memory manipulation jobs corresponding to only one object in the application code, or a plurality of memory manipulation operations corresponding to a plurality of objects in the application code. Please note that in one embodiment, the memory manipulation job loaded is a binary executable object code. In addition, the loaded memory manipulation job is an executable intermediate code.

In this configuration, the term "master/controller" can be used, and each controlled (or secondary) machine M1, M3, ... Mn loads the corrected object (or category) and contains Newly modified by the master (or primary) machine (eg machine M2, or some other machine, such as machine X in Figure 15) on the computer communication network or other communication link or path The memory manipulates the job. In some minor changes to this "master/controller" or "primary/secondary" configuration, the computer communication network may be replaced by a shared storage device, such as a shared file system, or a shared File/file storage area, such as a shared database.

Please note that the corrections performed on each machine or computer are not required and often not the same or similar. What is needed is that they are modified in a sufficiently similar manner, and in accordance with the innovative principles described herein, each step of the plurality of machines performs consistently and harmonically for the other machines described herein. Homework and purpose. Furthermore, it will be appreciated from the description provided herein that there are numerous ways in which modifications can be implemented, such as depending on the particular hardware, architecture, operating system, application code, or the like or other factors. It will also be appreciated that embodiments of the present invention may or may not have the benefit of being within an operating system, or within any operating system, within an EPROM, in a software, firmware, or It is implemented in any combination of these.

In still other embodiments, each machine M1, . . . , Mn receives the uncorrected asset (eg, category or item) containing one or more memory manipulation jobs, but corrects the job and then Enter an asset (such as a category or object) that contains the currently corrected job. While a machine (e.g., the master or primary machine) can customize or perform a different correction to a memory manipulation job that is transmitted to each machine, this embodiment can immediately make minor corrections made by each machine. Different, and improved, customized, and/or optimized based on their specific machine architecture, hardware, processor, memory, configuration, operating system, or other factors, yet still similar, reconciled, and consistent with other machines All other similar corrections and features need not necessarily be similar or identical.

In all of the specific embodiments described, the asset code (eg, a category code or an object code) is supplied or transmitted to the machines M1, . . . Mn, and a machine X of FIG. 15 is included as needed. Branching, decentralizing or transmitting between any combination or arrangement of different machines; for example by providing direct machine-to-machine communication (eg, supplying each M1, M3, M4, etc. directly from M2), or by providing or using a serial connection Or serial communication (eg, M2 supplies M1, which then supplies M3, then M4, and so on), or the combination of direct and concatenated and/or serial.

Please refer to Appendix A attached, where: Appendix A5 is a typical code segment from a memory manipulation operation (for example, an example unmodified example with a memory manipulation operation), and Appendix A6 is The same example with a memory manipulation operation after correction (for example, an example with an exemplary modification of a memory manipulation operation). These code segments are merely exemplary and a software code means can be identified for performing the corrections in an exemplary language. It will be appreciated that other software/firmware or computer code can be used to accomplish the same or similar functions or operations without departing from the invention.

Appendixes A5 and A6 (also reproduced in Tables VI and VII below) are exemplary codelists that provide an example of a conventional or uncorrected computer program software code (for example, for use in a single machine or computer environment). ), which has one of the application code 50 memory manipulation operations, and a post-correction excerpt of the same example, such as may be used in the specific embodiment of the present invention having multiple machines. The corrected code added to the example is highlighted in bold text.

It should be noted that the compiled code in the appendix and the part in the form repeated in the table are in the form of the file "example.java", which is included in Appendix A7 (Table VIII). In the procedures of Appendix A5 and Table VI, the program name "Method void setValues(int, int)" of step 001 is the name of the decoded output of the display of the setValues method of the compiled code of "example.java". The name "Method void setValues(int, int)" is optional, and this example is chosen to represent a typical JAVA method that includes a memory manipulation job. The entire method is responsible for completing the description by using a memory manipulation specification ("putstatic" and "putfield" in this example) and the steps to write two values or two different memory locations. The purpose.

First (step 002), the Java virtual machine instruction "iload_1" causes the Java virtual machine to load the integer value in the local variable array at index 1 of the current method frame, and store the item in the current method. The top of the stack of boxes, and causes the integer value to be passed to this method as the first argument, and stored in the local variable array of index 1 and pushed onto the stack.

The Java virtual machine instruction "putstatic #3<Field int static Value>" (step 003) causes the Java virtual machine to push the topmost value out of the stack of the current method frame and store the value to the method containing the setValues() method. The third field of the application's classfile structure is in the static field specified by the CONSTANT Fieldref info constant-pool item, and the uppermost value of the stack of the current method frame is stored in a file called "staticValue". In the integer field.

The Java virtual machine instruction "aload_1" (step 004) causes the Java virtual machine to load the item in the local variable array at index 0 of the current method frame and store the item in the stack of the current method frame. At the top, causing the "this" object to be referenced in the local variable array stored in index 0 and pushed onto the stack.

First (step 005), the Java virtual machine instruction "iload_2" causes the Java virtual machine to load the integer value in the local variable array at index 2 of the current method frame, and store the item in the current method frame. The top of the stack, and causes the integer value to be passed to this method as the first argument, and stored in the local variable array of index 2, and pushed onto the stack.

The Java virtual machine instruction "putfield #2<Field int instanceValue>" (step 006) causes the Java virtual machine to push the top two values out of the stack of the current method frame, and by storing the top value in the sample setValues The CONSTANT_Fieldref_info constant-pool item specified in the second index of the application's classfile structure, and causes the integer value above the stack of the current method frame to be stored in the object referenced as "instanceValue" In the field, below the integer value of the stack.

Finally, the JAVA virtual machine instruction "return" (step 007) causes the JAVA virtual machine to abort execution of the setValues() method by returning control to the previous method frame and causing the execution of the setValues() method to be aborted.

Due to the steps of working on a single machine configured in the first and second figures, the JAVA virtual machine manipulates (ie, writes) the staticValue and instanceValue memory locations, and performs the operation including the memory operations. The setValues() method guarantees that the memory is exactly the same as and maintains the consistency between multiple threads of a single application, thus ensuring unwanted behavior (such as multiple threads like a single application example). Inconsistent or non-harmonized memory between such inconsistent or uncoordinated memories, such as incorrect or different values or contents relative to a single memory location, does not occur). If these are to be performed on the plurality of machines configured in Figures 5 and 8, by executing the application code 50 synchronously on each of the plurality of machines M1...Mn, at each The memory manipulation jobs that occur for each of the simultaneously executing applications on the machine will be executed, but without any coordination between other machines, such as updating the corresponding memory locations on each machine, Each of them returns an identical content or value. This prior art configuration will not be able to perform this consistency, coordination, and reconciliation of memory across multiple complexes, with the goal of aligning, coordinating, and reconciling the memory state and manipulation and update operations across multiple machines. Status and manipulation and update jobs, as each machine performs memory manipulation only locally and does not attempt to coordinate or update their local memory with any other similar memory state on any or more than one machine. Status and operation. Therefore, this configuration may result in inconsistent and unharmonized memory states between the machines M1..Mn due to uncoordinated, inconsistent, and/or unharmonized memory manipulation and update operations. Accordingly, it is an object of the present invention to overcome the limitations of this prior art configuration.

In the example code of Table VII (Appendix A6), the code has been corrected, so it solves the consistency of the complex machine M1...Mn that could not be solved in the code example from Table VI (Appendix A5). Coordinated memory manipulation and update operation problems. In the modified setValues() method code, an "ldc#4<String" example"> instruction is inserted after the "putstatic #3" instruction, making it the first after executing the "putstaic #3" instruction. The instruction causes the JAVA virtual machine to load the string value "example" onto the stack of the current method frame, and causes the string value "example" to be loaded to the top of the stack of the current method frame. This change is obvious because it fixes the setValues() method to load a string identifier corresponding to the category name containing the category of the static field position written to the stack by the "putstatic #3" instruction. .

Furthermore, the JAVA virtual machine instruction "iconst_0" is inserted after the "ldc #4" instruction, so the JAVA virtual machine loads the integer value "0" onto the stack of the current method frame and causes the integer value "0" is loaded to the top of the stack of the current method frame. This change is obvious because it fixes the setValues() method to load an integer value, which in this example is "0", which represents the memory location manipulated by the previous "putstatic #3" job (field Identification. It is to be noted that the selection or specific form of the memory identification item used to practice the invention is for illustrative purposes only. In this example, the integer value "0" is the identification of the memory location for the manipulation and corresponds to the "staticValue" field as the first field of the "example.java" application, as in the appendix. As shown in A7. Thus, corresponding to the "putstatic #3" instruction, the "iconst_0" instruction loads the integer value "0" of the index of the field corresponding to the manipulation of the "putstatic #3" instruction, and in this example The first field of "example.java", so the "0" integer index value is on the stack.

In addition, the JAVA virtual machine instruction "invokestatic #5<Method boolean alert(java.lang.Object, int)>" is inserted after the "iconst_0" instruction, so the JAVA virtual machine pushes the top two items out of the current method. The stack of frames (which is referred to the string object according to the previous "ldc #4" instruction, and has the value "example" corresponding to the name of the category to which the manipulated field belongs, and the integer "0" corresponds to The example.java application indexes the manipulation field) and causes the "alert" method to send the top two items to push the stack to the new method frame as its first two arguments. This change is obvious because it fixes the setValues() method to execute the "alert" method and related jobs, corresponding to the previous memory manipulation job of the setValues() method (that is, the "putstatic #3" instruction) ).

Similarly, in this modified setValues() method code, an "aload_0" instruction is inserted after the "putfield #2" instruction, making it the first instruction after executing the "putfield #2" instruction. This causes the JAVA virtual machine to load the exemplified object of the example category of the manipulation field to which the previous "putfield #2" instruction belongs to the stack of the current method frame and cause the instruction to be written corresponding to the "putfield #2" instruction. The object reference of the entered example field is loaded onto the stack of the current method frame. This change is obvious because it corrects the setValues() method to load a reference to the object corresponding to the manipulation field onto the stack.

Furthermore, the JAVA virtual machine instruction "iconst_1" is inserted after the "aload_0" instruction, so the JAVA virtual machine loads an integer value "1" onto the stack of the current method frame and causes an integer value of "1". "Loaded above the stack of the current method frame. This change is obvious because it fixes the setValues() method to load an integer value, which in this example is "1", which represents the memory location (field) manipulated by the previous "putfield #2" job. Identification. It is to be noted that the selection or specific form of the identification items used to implement the invention is only for the purpose of illustration. In this example, the integer value "1" corresponds to the "instanceValue" field as the second field of the "example.java" application, as shown in Appendix A7. Thus, corresponding to the "putfield #2" instruction, the "iconst_1" instruction loads the integer value "1" corresponding to the index of the field of manipulation of the "putfield #2" instruction, and in this example, The second field of "example.java", hence the "1" integer index value, is loaded onto the stack.

In addition, the JAVA virtual machine instruction "invokestatic #5<Method boolean alert(java.lang.Object, int)>" is inserted after the "iconst_1" instruction, so the JAVA virtual machine launches the top two items leaving the current Stack of method frames (which is based on the previous "aload_0" instruction as a reference to the object to which the illustrated field of the manipulation belongs, and the integer "1" corresponds to the column in the manipulation of the example.java application Bit index) and cause the "alert" method to send the top two items of the stack to the new method frame as its first two arguments. This change is obvious because it fixes the setValues() method to execute the "alert" method and related jobs, corresponding to the previous memory manipulation job of the setValues() method (that is, the "putfield #2" instruction ).

The method void alert(java.lang.Object, int) is part of the FieldAlert code of Appendix A8 and part of the Decentralized Execution Time System (DRT) 71, requiring or otherwise notifying the implementation of the FieldSend.java code of Appendix A9. One of the DRT threads 121/1 updates and transmits the identification and value of the change in the memory position of the manipulation to the complex machine M1...Mn.

It will be understood that the modified code allows the memory to operate in coordination in a distributed computing environment having a plurality of computers or computing machines, so that no correction is made on the complex machine M1...Mn. Problems with the operation of the code or program (such as inconsistent and unharmonized memory states and manipulation and update operations) do not occur when the modified code or program is applied.

initialization

Please return to Figure 14 again, which shows an architectural diagram of a single prior art computer operating as a JAVA virtual machine. In this way, a machine (manufactured by any of a number of manufacturers and having an operating system operating in any of a number of different languages) can operate in a particular language of the application code 50, in this case In the middle of the JAVA language. That is, a JAVA virtual machine 72 is capable of operating the application code 50 in the JAVA language and utilizing a JAVA architecture that is independent of the machine manufacturer and the internal details of the machine.

When implemented in a non-JAVA language or application code environment, the generalized platform, and/or virtual machine, and/or machine, and/or execution time system are capable of operating an application code 50 in the language of the platform. (may include, for example, but not limited to, any one or more of a source code language, a mediation code language, an object code language, a machine code language, and any other code language), and/or a virtual machine, and/or machine, and/or Execute the time system environment and utilize the platform, and/or virtual machine, and/or machine, and/or execution time system, and/or language architecture, regardless of the machine manufacturer and internal details of the machine. It will also be appreciated in the description provided herein that the platform and/or execution time system can include virtual machine and non-virtual machine software and/or firmware architectures, as well as hardware and direct hardware coding applications and implementations.

Returning to the example of the JAVA language virtual machine environment, in the JAVA language, when a given category file 50A is loaded, only one category initialization instance <clinit> occurs. However, the object initialization example <init> occurs quite often, for example, the object initialization routine typically occurs each time a new object (eg, an object 50X, 50Y, or 50Z) is created. In addition, in the execution environment system environment of the JAVA environment and other machine or other usage categories and object structures, the category (usually a wider category than the object) is loaded before the object (which is a narrower category, and wherein the object It belongs to or is recognized as a specific category), so in the application code 50 shown in FIG. 14, it has a single category 50A and three objects 50X, 50Y and 50Z, and the first category 50A is loaded first. The first object 50X is then loaded, then the second object 50Y is loaded, and finally the third object 50Z is loaded.

As for the specific embodiment shown in Fig. 14, in which there is only a single computer or machine 72 (and a computer or machine to which a plurality of parts are connected or coupled), the initialization example (such as category and object initialization example) is executed. There is no conflict or inconsistency in it, it will be a job during the loader, because for a custom job, each initialization instance is executed only once by the single virtual machine or machine or execution time system or locale. Each of the one or more categories and one or more items may belong to or be identified as the category, or equivalent, where the term category and the item are not used.

For a more general combination of virtual machine or abstract machine environments, and for current and future computer and/or computing machines and/or information appliances or processing systems, and which may or may not utilize categories and/or The structure, method, computer program and computer program product of the present invention will still be applicable. Examples of computers and/or computing machines that do not utilize categories and/or objects include, for example, x86 computer architectures manufactured by Intel Corporation and others, SPARC computer architectures manufactured by Sun Microsystems and others, and by IBM Corporation. And the PowerPC computer architecture manufactured by other companies, as well as personal computer products manufactured by Apple Computer and other companies. For these types of computers, computing machines, information appliances, and virtual machines or virtual computing environments that are not implemented using categories or objects, for example, they can be generalized to include basic data types (eg, integer data types). Different, floating point data type, long integer data type, double data type, string data type, symbol data type and Bolling data type), structured data type (such as array and record) Type, or other code or data structure of other procedural languages, or other languages and environments, such as functions, indicators, components, modules, structures, references, and collections.

Returning to the example of the JAVA language virtual machine environment, in the JAVA language, when a given category file 50A is loaded, only one category initialization instance <clinit> occurs. However, the object initialization example <init> occurs quite often, for example, the object initialization routine typically occurs each time a new object (eg, an object 50X, 50Y, or 50Z) is created. In addition, in the execution environment system environment of the JAVA environment and other machine or other usage categories and object structures, the category (a wider category than the object) is loaded before the object (which is a narrower category, and wherein the object belongs to or It is recognized as a specific category), so in the application code 50 shown in Fig. 14, it has a single category 50A and three objects 50X-50Z, the first category 50A is first loaded, and then loaded into the first An object 50X is then loaded into the second object 50Y and finally loaded into the third object 50Z.

As for the specific embodiment shown in FIG. 14, in which there is only a single computer or machine 72 (and a machine that is not connected or coupled by a plurality of parts), the initialization example is executed (ie, the category initialization example <clinit> and There is no conflict or inconsistency in the object initialization instance <init>, which will be run during the loader, because for a custom job, each initialization instance is only executed by the single virtual machine or machine. The time system or locale is executed once, and may belong to or be identified as each of the one or more categories and one or more items as needed.

However, in the configuration illustrated in Figure 8 (also in Figures 31-33), it provides a plurality of individual computers or machines M1, M2, ... Mn, each of which is transmitted through a communication network 53 or Other communication links are interconnected, and each individual computer or machine has a modifier 51 (see Figure 5) and is released, for example, by the Decentralized Execution Time (DRT) 71 (see Figure 8). And loaded with a shared application code 50. The term shared application is understood to mean an application or application code written to be executed on a single machine and loaded on the computer or machine M1, M2...Mn in whole or in part. Or, as needed, on each of the plurality of sub-sets of the plurality of computers or machines M1, M2...Mn. But somewhat differently, there is a shared application, represented by application code 50, and this single copy or possibly multiple identical copies are modified to produce a modified copy or version of the application or code, each A copy or illustration is prepared to be executed on the plurality of machines. After they are corrected, they are considered to be shared if they perform similar jobs and operate consistently and harmonically. It will be appreciated that a plurality of computers, machines, information appliances, or the like, embodying features of the present invention, may be coupled or coupled to other computers, machines, information appliances, or the like that do not implement the features of the present invention, as desired.

In some embodiments, some or all of the plurality of individual computers or machines may be contained within a single enclosure or enclosure (eg, a so-called blade server, by Hewlett-Packard Development, Intel Corporation, IBM Corporation, and others). Manufactured) either on a single printed circuit board or even in a single wafer or wafer set.

Basically, the corrector 51 or the DRT 71 or other code correction means is responsible for correcting the application code 50, so that it can perform initialization routines or other initialization operations in the JAVA language and the virtual machine environment, for example, in the JAVA language and A class and object initialization method or exemplification in a virtual machine environment is in a coordinated, consistent, and harmonized manner and spans between the plurality of individual machines M1, M2...Mn. It is therefore necessary in this computing environment to ensure that local objects and classes on each individual machine M1, M2...Mn are initialized in a consistent manner (relative to each other).

It will be appreciated that under the description herein, the modifier 51 and the distributed execution time 71 will have additional implementations. For example, the modifier 51 can implement or be within a component of the distributed execution time 71, such that the DRT 71 can implement the functions and operations of the modifier 51. In addition, the function and operation of the corrector 51 can be implemented in addition to the structure, software, firmware or other means for implementing the DRT 71. In a specific embodiment, the modifier 51 and the DRT 71 are implemented or written in a single paragraph of the computer code, and the functions of the DRT and the modifier are provided. Therefore, the modifier function and structure may be included in the DRT and be regarded as an optional component. In addition to how it is implemented, the modifier function and structure is responsible for modifying the executable code of the application code program, and the distributed execution time function and structure is responsible for implementing communication between the computers or machines. The communication functions in a particular embodiment are implemented by an intermediate protocol layer within the computer code of the DRT on each machine. For example, the DRT can implement a communication stack in the JAVA language and use the Transmission Control Protocol/Internet Protocol (TCP/IP) to provide communication or conversation between the machines. In fact, how these functions or operations are implemented or divided between structural and/or procedural elements, or between the computer code or data structure of the present invention, is less important than the ones they provide.

In order to ensure that there is a consistent category and object (or equivalent) initialization state and initialization operation between the machines M1, M2, ..., Mn, the application code 50 is analyzed or thinned by searching the entire executable application code 50. Detecting, by means of detecting a program step (eg, a specific instruction or type of instruction) in the application code 50, which may define or constitute or otherwise represent an initialization job or modality (or other similar memory, resource, material or Code initialization example or job). In the JAVA language, these program steps include, for example, a "<init>" or "<clinit>" method that has or has some or all of an object or category, and is optionally associated with an "<init>" as needed. Or other code, instance or method of the "<clinit>" method, such as by a subject of "<init>" of the "<clinit>" method, evoking a different method.

The analysis or scrutiny of the application code 50 may occur prior to loading the application code 50, or during loading of the application code 50, or even after the application code 50 loads the program. It can be similar to an installation, program conversion, translation, or compiler, where the application code can be implemented with additional instructions, and/or can be modified by meaning retention program manipulation, ie, or alternatively by an input code language. Translating into a different code language (for example, translation from a source code language or an intermediate code language to an object code language or a machine code language), and knowing that the term compilation usually or customally contains changes in the code or language, such as From source code or object code, or from one language to another. However, in this example the term "compilation" (and its grammatical equivalents) is not so limited and may include or contain amendments within the same code or language. For example, the compilation and its equivalents can be understood to include both normal compilation (eg, by way of illustration and not limitation, from source code to object code), and compiled from source code to source code, and compiled from object code to object. The code, and any combination of any of them. It may also include a so-called "mediation code language" in the form of "virtual object code".

By way of illustration and not limitation, in one embodiment, analysis or scrutiny of the application code 50 may occur during loading of the application code, such as by the operating system from the hard disk or other storage device or source. The application code is read, copied to memory, and ready to begin execution of the application code. In another embodiment, in a JAVA virtual machine, the analysis or scrutiny can occur during a class loader of the java.lang.ClassLoader loadClass method (eg, java.lang.ClassLoader.loadClass()).

In addition, the analysis or scrutiny of the application code 50 can occur even after the application code loading program, for example, after the operating system has loaded the application code into the memory, or alternatively even in the application code. After the relevant part has been started or carried out, for example, after the JAVA virtual machine has loaded the application code into the virtual machine, it passes the "java.lang.ClassLoader.loadClass()" method, and Execute selectively.

Therefore, the above analysis or observation, the initialization example (such as <clinit> category initialization method and <init> object initialization method) is initially found, and when a correction code is found or recognized, a correction is triggered. Initialize the example. The modified example is modified and written to initialize the category 50A on one of the machines, such as JVM #1, and tell, notify or otherwise pass to all other machines M2,..., Mn, This category 50A exists and is in a state of initialization as needed. There are several different modes in which this correction and loading can be done.

So in one mode, the DRT 71/1 on the loading machine, in this case the Java Virtual Machine M1 (JVM#1), requires all other machines M1,..., Mn DRT's 71/2. ..71/n if a similar equivalent first category 50A is initialized on any other machine (ie has been initialized). If the answer to this question is "yes" (that is, a similar class 50A has been initialized on another machine), then the execution of the initialization instance is aborted, paused, terminated, closed, or otherwise on the machine. Class 50A on JVM#1 is disabled. If the answer is "No" (that is, if a similar category 50A has not been initialized on another machine), then the initialization job continues (or restarts, or starts, or proceeds, and the category 50A is initialized, And as needed, the continuous change (such as, for example, the initialized code and data structure in the memory) is transferred to the initialization instance to be brought into each similarly-like local category on each of the other machines, As indicated by arrow 83 in Fig. 8.

A similar procedure occurs every time an object (such as 50X, 50Y or 50Z) is loaded and initialized. When the DRT 71/1 of the loading machine, in this example, the Java machine M1 (JVM#1) is not recognized, due to the quality of other machines M2...Mn, an equivalent object is to be on the machine M1. The specific object that is initialized, ie, the object 50Y, which has been initialized by another machine, the DRT 71/1 on the machine M1 can perform an object initialization example corresponding to the object 50Y, and each of the other machines M2 as needed. ... Mn can load an equivalent local object (which can conveniently be referred to as a dot object), and related subsequent changes brought into by the execution of the initialization job on machine M1 (eg, like initialization data, initialization) Code, and / or initialized system or resource structure). However, if the DRT 71/1 of the machine M1 determines that one of the problematic items 50Y is equivalent to the equivalent object that has been initialized on another machine of the plurality of machines (eg, such as machine M2), then corresponds to the object 50Y. The machine M1 of the initialization function, the routine or the program does not start or perform, or otherwise suspends, terminates, closes or otherwise disables, and loads the object 50Y on the machine M1, preferably but if necessary Subsequent changes (such as, for example, initialized data, initialized code, and/or other initialized systems or resource structures) are initialized by machine M2, i.e., loaded onto machine M1 corresponding to object 50Y. Again, there are a number of ways to bring out the desired results.

Preferably, the execution of the initialization routine is configured to a machine, such as the first machine M1 to load (and, if necessary, to initialize) the object or category. Corresponding to the execution of an initialization routine that determines that a particular category or object (and any similar local categories or objects on each machine M1...Mn) has not been initialized, ie only for all machines M1...Mn Once, preferably by only one machine, it represents all machines M1...Mn. For the application, and preferably by following the initialization of a machine (such as machine M1), then each of the other machines is loaded with a similar equivalent local object (or category) and loaded as needed Subsequent changes (such as, for example, initialized data, initialized code, and/or other initialized systems or resource structures) are brought in by the execution of the initialization job of machine M1.

As can be seen from Fig. 15, the modification of the general configuration of Fig. 8 provides that the machines M1, M2...Mn are as before, and perform the same simultaneously or synchronously on all machines M1, M2...Mn The application code is 50 (or many codes). However, the previous configuration was modified by the provision of a server machine X, which is conveniently capable of supplying housekeeping functions, such as, and in particular, initialization of structures, assets, and resources. This server machine X can be a low value commercial computer, such as a PC, because of its low computational load. As indicated by the dashed lines in Figure 15, the two server machines X and X+1 can be provided for redundancy purposes to increase the overall reliability of the system. When both server machines X and X+1 are provided, they are preferably, but can be operated as, redundant machines in a non-failed environment.

It does not need to provide a server machine X because its computational load can be spread over the machines M1, M2...Mn. In addition, a database operated by a machine (in a master/controlled class job) can be used for housekeeping functions.

Figure 16 shows a preferred general procedure to follow. After a load step 161 has been performed, the instructions to be executed are considered sequentially, and all initialization routines are detected as shown in step 162. In the JAVA language, these and object initialization methods (such as <init>) and category initialization methods (such as <clinit>). Other languages use different terms.

When an initialization routine is detected in step 162, it is modified in step 163 to perform the initialization, coordination, and reconciliation initialization operations across the complex machine M1, M2...Mn ( For example, the initialization of the data structure and the code structure, basically by inserting other instructions into the initialization example, for example, determining the machine M1 corresponding to the object or category (or asset) corresponding to the initialization example. A similar object or class (or other asset) on Mn has been initialized, if so, aborting, pausing, terminating, closing, or otherwise disabling the execution of the initialization routine (and or initializing the job), if If not, start, continue, or restart the execution of the initialization example (ie, or initialization job), and instruct other machines M1...Mn as needed to load an equivalent object or category, and initialize by Subsequent changes brought about by the execution of the example. In addition, the correction command can be inserted before the example, such as before an instruction or job that performs initialization of the corresponding category or object. Once the modification step 163 has completed the loading procedure, and continues to load the modified application code to replace the uncorrected application code, as shown in step 164. In summary, the initialization example is only to be executed once, preferably by only one machine, representing all machines M1...Mn, which corresponds to the determination of all machines M1...Mn, the particular object or category (i.e., similar native objects or categories on each machine M1...Mn, which correspond to the particular object or category associated with this initialization example) have not yet been initialized.

Figure 17 shows a specific form of correction. In step 171

After the example, the structure, asset, or resource to be initialized (the term of the JAVA is a category or object) is configured in step 172 with a name or label (eg, a generic name or label) that can be used to identify each machine. M1,..., corresponding to equivalent local objects on Mn. This is most conveniently accomplished by a form (or similar material or record structure) maintained by the server machine X of Figure 15. This table may also include initialization status similar to the equivalent category or object to be initialized. It will be appreciated that this form or other data structure may only store the initialization state, or it may store other states or information. As shown in FIG. 17, steps 173 and 174 are determined by DRT 71 to determine that similar local objects on each of the other machines corresponding to the common name or tag have not been initialized (ie, by steps 173 and 174). Not yet initialized on a machine other than the machine that is doing the loading and searching to perform initialization), then this means that the object or category can be initialized, preferably but in the normal way, as needed The execution of the initialization routine is initiated, performed, continued, or restarted, as shown in step 176, because it is the same as the equivalent local object or category of the machine M1...Mn to be initialized. One.

In a specific embodiment, the initialization routine is either initialized or started or begins to execute; however, in some implementations, it is difficult or practically impossible to stop the initialization routine from initializing or starting or performing. Thus, in another embodiment, the execution of the initialization routine that has been initiated or performed is aborted such that it does not complete or does not complete in its normal manner. This additional suspension can be understood to include an actual interrupt, or a hold, or a delay, or a pause in the execution of an initialization routine that has already begun execution (regardless of the execution phase prior to completion), thus ensuring the initialization routine There is no opportunity to perform to complete the initialization of the object (or category or other asset), and thus the object (or category or other asset) remains "uninitialized" (ie, "not initialized").

But or in addition, if steps 173 and 174 determine a generic name corresponding to the equivalent portion of the equivalent local object or category, each of which is on one of the plurality of machines M1...Mn, which is already on another machine Initialized, then this represents that the object or category is considered representative or initialized for the complex machine M1...Mn. Thus, execution of the initialization routine is aborted, terminated, closed, or otherwise disabled by performing step 175.

Figure 18 illustrates a specific embodiment of step 173 of Figure 17, showing the query by the loader (one of M1, M2...Mn) to the server machine X of Figure 15, It queries the initialization status of a plurality of similar local objects (or categories) corresponding to the common name. The loading machine operation is temporarily interrupted, as shown in step 181, and corresponds to step 173 of Figure 17, until the reply is received from machine X for the previous request, as shown in step 182. In step 181, the loading machine transmits a query message to machine X requesting an initialization state of the object (or category or other asset) to be initialized. Next, the load machine waits for a reply from machine X corresponding to the query message transmitted by the requesting machine in step 181, as shown in step 182.

Figure 19 shows the activity performed by machine X of Figure 15 in response to such an initialization query of step 181 of Figure 18. The initialization state is determined in steps 192 and 193, which determines if a similar equivalent (or class or other asset) corresponding to the initialization status of the generic name is required, as received in step 191, on another machine. Initialized (i.e., a machine other than the query machine 181 initiated by the initialization state of step 191), wherein a table of initialization states is queried for a record corresponding to the common name, and if the initialization status record indicates A similar local object (or category) on another machine (eg, in one of the machines M1...Mn) and corresponding to a common name has been initialized, the response to this effect is performed Step 194 is transmitted to the query machine. In addition, if the initialization status record is indicated on another machine (eg, on a portion of the plurality of machines M1...Mn), and corresponding to the common name is uninitialized, a corresponding reply is performed by the step 195 and 196 are transmitted to the inquiry machine. The terminology object or category (or equivalent term asset or resource used in step 192) as used herein is to be understood to include all such equivalent items (or categories, or assets, or resources) corresponding to the plural The same generic name on each of the machines M1...Mn. Then, the waiting query machine of step 182 can respond and/or work accordingly, such as by (i) suspending (or suspending, or delaying) execution of the initialization routine, when the reply from machine X in step 182 indicates Another machine (e.g., one of the plurality of machines M1...Mn) has an equivalent local object corresponding to the generic name of the object to be initialized in step 172 that has been initialized at it ( That is, initialized on a machine other than the machine that is proposing the initialization; or (ii) by continuing (or restarting, or starting, or proceeding) the execution of the initialization routine, when in step 182 The reply from machine X indicates that one of the plurality of machines M1...Mn is similar to the equivalent local object corresponding to the generic name of the object to be initialized at step 172 has not been initialized at it (ie, except for the initialization to be initiated) It is not initialized on a machine other than the machine).

Please refer to the attached appendix, where: Appendix A1-A10 shows the actual code associated with the field, Appendix B1 is a typical code segment from one of the uncorrected <clinit> instructions, and Appendix B2 corresponds to a correction. The equivalent of the <clinit> instruction, Appendix B3 is a typical code segment from one of the uncorrected <init> instructions, and Appendix B4 is the equivalent of a modified <init> instruction. In addition, Appendix B5 is another option for the code in Appendix B2, and Appendix B6 is another option for the code in Appendix B4.

Furthermore, Appendix B7 is the source code of InitClient, which performs a specific embodiment of the steps of FIGS. 17 and 18, the query corresponding to the plurality of similar categories on the plurality of machines M1...Mn or An "initialization server" (eg, a machine X) that initializes the specified category or object of the object. Appendix B8 is the source code of the InitServer, which performs a specific embodiment of the steps of Figure 19, which receives an initialization status query transmitted by the InitClient and responds to return the corresponding initialization status of the specified category or object. Similarly, Appendix B9 is the source code for this example application (repeated in Table X to XV) used in the previous/after examples of Appendix B1-B6. Also, Appendix B10 is the source code of InitLoader, which performs a specific embodiment of the steps of Figures 16, 20 and 21, which modifies the exemplary application code of Appendix B9 in accordance with one mode of the present invention.

Appendixes B1 and B2 (also partially reproduced in Tables X and XI below) are exemplary code list columns that provide the conventional or uncorrected computer program software code for an initialization example of the application 50 (eg A post-correction excerpt of the same initialization equations, which can be used in a single machine or computer environment, for example, can be used in the specific embodiment of the invention having multiple machines. The corrected code added to the initialization example is highlighted in bold text.

It should be noted that the compiled code in the appendix and the part in the form repeated in the table are in the form of the file "example.java", which is included in Appendix B4 (Table XIII). In the procedures of Appendix B1 and Table X, the program name "Method<clinit>" of step 001 is the name of the decoded output of the display of the clipit method of the "example.java" compiled with the application code. The method name <clinit> is the name of the initialization method according to one of the JAVA platform specifications, and this example is selected to represent a typical mode of the operation of a JAVA initialization method. The entire method is responsible for initializing the class 'example', so it can be used, and the steps performed by the "example.java" code are described here in order.

First (step 002), the JAVA virtual machine instruction "new #2<Class example>" causes the JAVA virtual machine to enumerate the second index of the classfile structure stored by the application containing the sample <clinit> method. An example of a new category of the example category specified by the CONSTANT_Classref_info constant_pool item, and causing an object referenced to a newly generated type 'example' to be placed (pushed) in the current method frame of the currently executing thread On the stack.

Next (step 003), the Java virtual machine command "dup" causes the Java virtual machine to copy the topmost item of the stack, and push the copied item to the top position of the stack of the current method frame, and cause The reference to the newly generated 'example' object is copied and pushed onto the top of the stack on the stack.

Receiving (step 004), the JAVA virtual machine instruction "invokespecial #3<Method example()>" causes the JAVA virtual machine to launch the stack of the top method frame leaving the current method frame and cause the object to be pushed out This example initializes the method "<init>" and causes the "<init>" structure of the newly generated 'example' object.

The Java virtual machine instruction "putstatic #3<Field example currentExample>" (step 005) causes the Java virtual machine to push the stack of the highest value from the current method frame and store the value in the sample containing <clinit> Method of the third index of the classfile structure of the application in the CONSTANT_Fieldref_info constant-pool item specified in the static field, and causing the reference to the newly generated and initialized 'example' object in the current method frame Above the stack, it is stored in the static reference field of the category 'example' named 'currentExample'.

Finally, the Java virtual machine instruction "return" (step 006) changes the previous method frame by the return control to cause the Java virtual machine to stop executing the <clinit> method and cause termination of execution of the <clinit> method.

Due to these steps of working on a single machine of the conventional configuration of Figures 1 and 2, the JAVA virtual machine can trace the initialization state of a category by means of consistency, reconciliation and coordination, and perform the initialization operation including The <clinit> method guarantees that unwanted behavior will not occur (for example, the <init> method of the class 'example.java' that executes more than once), as caused by inconsistent and/or uncoordinated initialization jobs. If these steps are to be performed on a plurality of machines in the configuration of Figures 5 and 8, and have the memory update and transfer copying means of Figures 9, 10, 11, 12 and 13, and in the plural machine The application code 50 is executed synchronously on each of M1...Mn, and the initialization of each synchronously executed application event on each machine will not need to be between any other events on any other machine. Coordinated to proceed. Given the goal of an initialization job that spans the consistency, coordination, and reconciliation of a plurality of machines, this prior art configuration would not be able to perform such a consistent job of coherent coordination across the complex machine because each machine is only Initialization is performed locally and there are no attempts to coordinate their local initialization jobs to any other similar initialization jobs on any one or more other machines. This configuration will therefore have unwanted or otherwise anomalous behavior due to uncoordinated, inconsistent and/or unharmonized initialization states and associated initialization operations. Accordingly, it is an object of the present invention to overcome the limitations of the prior art.

In the sample code of Table XIV (Appendix B5), the code has been corrected, so it can solve the problem of the consistent coordination of the complex machines M1...Mn, which is not in Table X (Appendix B1). The code example is resolved. In the modified <clinit> method code, a "1dc #2<String" example">" instruction is inserted before the "new #5" instruction, and is the first instruction of the <clinit> method. This causes the JAVA virtual machine to load the project in the constant_pool of the current classfile index 2, and store the item above the stack of the current method frame, and cause the string object referenced to the value "example" to be pushed. Go to the stack.

Furthermore, the JAVA virtual machine instruction "invokestatic #3<Method Boolean isAlreadyLoaded(java.lang.String)>" is inserted after the "0 ldc #2" instruction, so the JAVA virtual machine launches the topmost item leaving the The current stack of method frames (which refer to the String object according to the previous "ldc #2" instruction, using the value "example" corresponding to the name of the category to which the <clinit> method belongs, and causing the "isAlreadyLoaded" "Method, passing the launched item to the new method frame as its first argument, and returning a Boolean value to the stack when the "invodestatic" instruction is passed back. This change is obvious because it fixes the <clinit> method to execute the "isAlreadyLoaded" method and related jobs, corresponding to the beginning of the execution of the <clinit> method, and returns a Boolean argument (representing whether to apply The class of this <clinit> method is initialized on another machine in the complex machine M1...Mn) to the stack of execution method frames of the <clinit> method.

Next, two JAVA virtual machine instructions "ifeq 9" and "return" are inserted into the code stream after the "2 invokestatic #3" instruction and before the "new #5" instruction. The first of these two instructions is the "ifeq 9" instruction, which causes the JAVA virtual machine to push the topmost item out of the stack and perform a comparison between the pushed value and zero. If the comparison of the execution is successful (ie if and only if the value of the push is equal to zero), execution continues to the "9 new #5" instruction. But if the comparison of the execution fails (i.e. if and only if the pushed value is not equal to zero), execution proceeds to the next instruction in the code stream, which is the "8 return" instruction. This change is particularly noticeable because it fixes the <clinit> method to continue executing the <clinit> method (ie, instructions 9-19) when the return value of the "isAlreadyLoaded" method is negative (ie "false"). Or when the "isAlreadyLoaded" method is positive (ie "true"), the execution of the <clinit> method is interrupted (ie the "8 return" instruction causes the return control to be caused by this <clinit> method). .

The method void isAlreadyLoaded (java.lang.String), part of the InitClient code of Appendix B7, and part of the Decentralized Execution Time System (DRT) 71, which performs communication operations between the machines M1...Mn, Coordinate the execution of the <clinit> method between the machines M1...Mn. The isAlreadyLoaded method of this example transmits the InitServer code of Appendix B8 executed on machine X of Figure 15, by transmitting an "initialization state request" to the machine X corresponding to the category being "initialized" (ie, this < The category to which the clinit> method belongs). Referring to FIG. 19 and Appendix B8, the machine X receives the "initialization state requirement" corresponding to the category to which the <clinit> method belongs, and causes an initialization state or a table of records to determine the initialization of the category corresponding to the request. status.

If the category corresponding to the initialization state requirement is not initialized on another machine other than the required machine, then machine X will send a response indicating that the category has not been initialized and update the corresponding to the specified A record entry for the category to indicate that the category is now initialized. Additionally, if the category corresponding to the initialization state requirement is initialized on another machine other than the required machine, machine X will send a response indicating that the category has been initialized. The category associated with determining the initialization state requirement is not initialized on another machine other than the required machine, generating a reply and transmitting to the requesting machine to indicate that the category has not been initialized. In addition, machine X preferably updates the entry corresponding to the category associated with the initialization state request to indicate that the category is now initialized. After receiving such a message from machine X, the class is not initialized on another machine, the isAlreadyLoaded() method and the job terminate execution, and a 'false' value is returned to the previous method frame. It is the execution method frame of the <clinit> method. In addition, after receiving a message from machine X, indicating that the class has been initialized on another machine, the isAlreadyLoaded() method and the job terminate execution, and return a 'true' value to the previous method frame. It is the execution method frame of the <clinit> method. After the job is returned here, execution of the <clinit> method frame is then resumed, as indicated in the code sequence of Appendix B5 in step 004.

It will be understood that the modified code allows the memory to operate in coordination in a distributed computing environment having a plurality of computers or computing machines, so that no correction is made on the complex machine M1...Mn. The problem of the code or program operation (such as, for example, multiple initialization jobs, or reinitialization of the job) does not occur when the modified code or program is applied.

Similarly, the next procedure is to modify the <init> method for one of the objects, whereby the code section of Appendix B3 (see Table XII) is converted to the code section of Appendix B6 (see Table XV).

Appendixes B3 and B6 (also partially reproduced in Tables XII and XV below) are exemplary code list columns that provide the conventional or uncorrected computer program software code for one of the application 50 initialization examples (eg, A post-correction excerpt of the same initialization equations, which can be used in a single machine or computer environment, for example, can be used in the specific embodiment of the invention having multiple machines. The corrected code added to the initialization example is highlighted in bold text.

It should be noted that the compiled code in the appendix and the part in the form repeated in the table are in the form of the file "example.java", which is included in Appendix B4. In the procedures of Appendix B1 and Table XI, the program name "Method<init>" of step 001 is the name of the decoded output of the display of the init method of "example.java" compiled with the application code. The method name <init> is the name of the initialization method (or method because there will be more than one) according to one of the JAVA platform specifications, and a typical mode for selecting an operation of a JAVA initialization method is selected for this example. The entire method is responsible for initializing an 'example' object, so it can be used, and the steps performed by the "example.java" code are described here in order.

The Java virtual machine instruction "aload_0" (step 002) causes the Java virtual machine to load the local variable array of the item at index 0 of the current method frame and store the item in the stack of the current method frame. Above, and causing this object to be referenced in the local variable array stored at index 0 and pushed onto the stack.

Next (step 003), the JAVA virtual machine instruction "invokespecial #1<Method java.lang.Object()>" causes the JAVA virtual machine to push out the stack of the top method item leaving the current method frame and cause This illustration of the launched object initializes the method "<init>" and causes the "<init>" structure (or method) of the superclass of the "example" object to be raised.

The Java virtual machine instruction "aload_0" (step 004) causes the Java virtual machine to load the item into the local variable array at index 0 of the current method frame and store the item in the stack of the current method frame. At the top, and causing the "this" object reference stored in the local variable array at index 0 to be pushed onto the stack.

Next (step 005), the JAVA virtual machine instruction "invokestatic #2<Method long currentTimeMillis()>" causes the JAVA virtual machine to cause the "currentTimeMillis()" method of the java.lang.System class, and causes a long value corresponding The top of the stack to which the return value from the currentTimeMillis() method is pushed is pushed.

The Java virtual machine instruction "putfield #3<Field long timestamp>" (step 006) causes the Java virtual machine to push the top two values out of the stack of the current method frame and store the topmost value in the second rollout The value instance field of the value, which is stored in the CONSTANT_Fieldref_info constant-pool item in the third index of the classfile structure of the application containing this example <init> method, and is caused at the top of the stack of the current method frame. The long value is stored in the example field named "timestamp" referenced by the object under the long value on the stack.

Finally, the Java virtual machine instruction "return" (step 007) causes the Java virtual machine to abort execution of the <init> method by returning control to the previous method frame and cause the execution of the <init> method to end.

Due to the steps of working on a single machine of the conventional configuration in Figures 1 and 2, the JAVA virtual machine can trace the initialization state of an object in a consistent, harmonic, and coordinated manner, and execute the initialization operation containing the initialization operation. The <init> method guarantees that unwanted behavior will not occur (such as the <init> method of a single 'example.java' object that is executed more than once, or the reinitialization of the same object), for example, by inconsistency and/or not Caused by the initialization of the reconciliation. If these steps are to be performed on a plurality of machines in the configuration of Figures 5 and 8, and have the memory update and transfer copying means of Figures 9, 10, 11, 12 and 13, and synchronously in the plural The application code 50 is executed on each of the machines M1...Mn, and each initialization job that executes the application event synchronously on each machine can be executed between any other event on any other machine. No coordination is required. Given the goal of an initialization job that spans the consistency, coordination, and reconciliation of a plurality of machines, this prior art configuration would not be able to perform such a consistent job of coherent coordination across the complex machine because each machine is only Initialization is performed locally and there are no attempts to coordinate their local initialization jobs to any other similar initialization jobs on any one or more other machines. This configuration will therefore have unwanted or otherwise anomalous behavior due to uncoordinated, inconsistent and/or unharmonized initialization states and associated initialization operations. It is therefore an object of the present invention to overcome the limitations of prior art configurations.

In the example code of Table XV (Appendix B6), the code has been corrected, so it solves the consistency and coordination of the complex machines M1...Mn that are not solved in the code example from Table XII (Appendix B3). The problem with the initialization job. In the modified <init> method code, an "aload_0" instruction is inserted after the "1 invokespecial #1" instruction because the "invokespecial #1" instruction must be executed before the object is further used. The inserted "aload_0" instruction causes the JAVA virtual machine to load the item into the local variable array at index 0 of the current method frame and store the item at the top of the stack of the current method frame, and The object reference that caused the "this" object at index 0 is pushed onto the stack.

Furthermore, the JAVA virtual machine instruction "invokestatic #3<Method Boolean isAlreadyLoaded(java.lang.Object)>" is inserted after the "4 aload_0" instruction, so the JAVA virtual machine launches the topmost item to leave the current method. a stack of frames (which refers to the object to which the <init> method belongs according to the previous "aload_0" instruction) and causes the "isAlreadyLoaded" method to transmit the pushed item to the new method frame as its An argument, and returns a Boolean value to the stack when returned by this "invokestatic" instruction. This change is obvious because it fixes the <init> method to execute the "isAlreadyLoaded" method and related jobs, corresponding to the start of the execution of the <init> method, and returns a Boolean argument (representing whether to apply The object of this <init> method is initialized on another machine in the complex machine M1...Mn) to the stack of execution method frames of the <init> method.

Next, two JAVA virtual machine instructions "ifeq 13" and "return" are inserted into the code stream after the "5 invokestatic #2" instruction and before the "12 aload_0" instruction. The first of these two instructions is the "ifeq 13" instruction, which causes the JAVA virtual machine to push the topmost item out of the stack and perform a comparison between the pushed value and zero. If the comparison of the execution is successful (ie if and only if the value of the push is equal to zero), then execution continues to the "12 aload_0" instruction. But if the comparison of the execution fails (ie if and only if the pushed value is not equal to zero), execution proceeds to the next instruction in the code stream, which is the "11 return" instruction. This change is particularly noticeable because it fixes the <init> method to continue executing the <init> method (ie, instructions 12-19) when the return value of the "isAlreadyLoaded" method is negative (ie "false"). Or when the "isAlreadyLoaded" method is positive (ie "true"), the execution of the <init> method is interrupted (ie, the "11 return" instruction causes the return control to be caused by the <init> method.

The method void isAlreadyLoaded (java.lang.Object), part of the InitClient code of Appendix B7, and part of the Decentralized Execution Time System (DRT) 71, which performs communication operations between the machines M1...Mn, Coordinate the execution of the <init> method between the machines M1...Mn. The isAlreadyLoaded method of this example transmits the InitServer code of Appendix B8 executed on machine X of Figure 15, by transmitting an "initialization state request" to the machine X corresponding to the object being "initialized" (ie, this < Init> the object to which the method belongs). Referring to Figure 19 and Appendix B8, machine X receives the "initialization state requirement" corresponding to the object to which the <clinit> method belongs, and causes an initialization state or a table of records to determine the initialization of the object corresponding to the request. status.

If the object corresponding to the initialization state requirement is not initialized on another machine other than the required machine, then machine X will send a response indicating that the object has not been initialized and updated corresponding to the specified A record entry for the object indicates that the object is now initialized. Additionally, if the item corresponding to the initialization state requirement is initialized on another machine other than the required machine, machine X will send a response indicating that the item has been initialized. The object corresponding to the decision determining the initialization state requirement is not initialized on another machine other than the required machine, generating a reply and transmitting to the requesting machine to indicate that the object has not been initialized. In addition, machine X preferably updates the entry corresponding to the object associated with the initialization state request to indicate that the object is now initialized. After receiving such a message from machine X, the object is not initialized on another machine, the isAlreadyLoaded() method and the job terminate execution, and a 'false' value is returned to the previous method frame. It is the execution method frame of the <init> method. In addition, after receiving a message from machine X, the object is already initialized on another machine, the isAlreadyLoaded() method and the job terminate execution, and a 'true' value is returned to the previous method frame. It is the execution method frame of the <init> method. After the job is returned here, execution of the <init> method frame is then resumed, as indicated in the code sequence of Appendix B5 in step 006.

It will be understood that the modified code allows the memory to operate in coordination in a distributed computing environment having a plurality of computers or computing machines, so that no correction is made on the complex machine M1...Mn. The problem of the code or program operation (such as, for example, multiple initialization, or reinitialization of the job) does not occur when the modified code or program is applied.

Appendix B1 is an excerpt from the pre-correction of the compiled form of the decoding of the <clinit> method of the example.java application of Appendix B9. Appendix B2 is the revised form of Appendix B1, which is modified by InitLoader.java of Appendix B10 according to the steps in Figure 20. Appendix B3 is an excerpt from the revision of the compiled form of the decoding of the <init> method of the example.java application of Appendix B9. Appendix B4 is the revised form of Appendix B3, and the steps according to Figure 21 are corrected by InitLoader.java of Appendix B10. Appendix B5 is another modified form of Appendix B1, which is modified by InitLoader.java in Appendix B10 according to the steps in Figure 20. And Appendix B6 is another modified form of Appendix B3. The steps according to Figure 21 are corrected by InitLoader.java of Appendix B10. These corrections are highlighted in bold.

Referring now to FIG. 20 and FIG. 21, the next procedure is to present the modified category initialization example (ie, the "<init>" method) and the object initialization example (ie, the "<init>" method). The following example modifies the <clinit> method for one of the categories, whereby the code segment of Appendix B1 (see Table X) is converted to the code segment of Appendix B5 (see Table XIV). Similarly, the next procedure is to modify the object initialization <init> method for an object, whereby it is indicated by the code section of Appendix B3 (see Table XII) to the code section of Appendix B6 (see Table XV).

Initial loading of the application code 50 (an exemplary example of the source code form shown in Appendix B9 and a corresponding part shown in Appendix B1 (see also Table X) and Appendix B3 (see also Table XII) The decoded form is sent to the JAVA virtual machine 72 in step 201, and the code is analyzed or scrutinized to detect one or more class initialization instructions, code blocks or methods (ie, "<clinit> "Method", performed by step 202, and/or one or more object initialization instructions, code blocks or methods (ie, "<init>" method), is performed by step 212. Once detected, a <clinit> method is modified by performing step 203, and an <init> method is modified by performing step 213. An example of a modified class initialization example is shown in Appendix B2 (see also Table XI), and another example is shown in Appendix B5 (see also Table XIV). An example of a modified object initialization example is shown in Appendix B4 (see also Table XIII), and another illustration is shown in Appendix B6 (see also Table XV). As shown in steps 204 and 214, after the correction is completed, the loader is continued such that the modified application code is loaded onto each machine instead of the uncorrected application code.

Appendix B1 (see also Table X) and Appendix B2 (see also Table XI) are the previous (or pre-corrected or uncorrected) and then (or after) a category initialization example (ie a "<clinit>" method) Extracted or corrected code). In addition, another example of another modified <clinit> method is illustrated in Appendix B5 (see also Table XIV). The corrected code added to the method is highlighted in bold text. In the decoded code example that is not partially modified in Appendix B1, the "new #2" and "invokespecial #3" instructions of the <clinit> method generate a new object (type 'example'), and the following The instruction "putstaitc #4" writes a reference to this newly generated object to the memory location (field) called "currentExample". Therefore, it is not necessary to manage the coordinated class initialization in the distributed environment of the plurality of machines M1, . . . , Mn, and each of the memory update and transfer means of the 9, 10, 11, 12 and 13 pictures is borrowed. The application code 50 is intended to operate as an example of a single coordination, consistency and reconciliation across one of the plurality of machines M1...Mn, each computer or computing machine utilizing multiple executions corresponding to the <clinit> method Multiple and different objects to reinitialize (and optionally rewrite or overwrite) the "currentExample" memory location (field), resulting in the application code 50 on each machine M1,..., Mn Possible non-harmonic or inconsistent memory between events. It is clear that this is not what a programmer or user of a single application code 50 would expect to happen.

Therefore, with the benefit of DRT, the application code 50 is modified to be loaded into the machine by changing the class initialization instance (i.e., the <clinit> method). The changes made (in bold) are the initial instructions executed by the modified <clinit> method. These added instructions determine the initialization state of this particular class by checking whether one of the other classes on this machine is similar to the equivalent local class, which has been initialized and loaded as needed, by calling An example is to determine the initialization state of the plurality of similar classes, such as the "is already loaded" (eg, "isAlreadyLoaded()") program or method. The "isAlreadyLoaded()" method of InitClient of Appendix B7 of DRT 71 executing steps 172-176 of Figure 17 determines the initialization state of similar equivalent local categories on each machine M1,..., Mn, corresponding to For the particular category being loaded, the result is a "true" result or a "false" result, which corresponds to whether another (or more) of the machines M1...Mn have been initialized, and Need to load a similar category.

The initialization decision method or method "isAlreadyLoaded()" of the InitClient of Appendix B7 of DRT 71 may optionally use an argument, which may represent a unique identifier of this category (see Appendix B5 and Table XIV). For example, the category name being considered for initialization, representing one of the categories or categories of objects that the category is being considered for initialization, or representing a unique number or identification across one of the machines (ie, corresponding to a plurality of Similar to one of the equivalent local categories, the unique identifiers, each of which is on the plurality of machines M1...Mn), are used to determine the initialization state of the plurality of parts of the same local class on each machine M1...Mn. In this way, the DRT can support the initialization of multiple categories at the same time without confusion, because the multiple categories or not yet loaded, have been loaded using the unique identifier of each category, the DRT 71 can have several possibilities The method to determine the initialization state of the category. Preferably, the requesting machine can sequentially request each of the other required machines (for example, by using a computer communication network to exchange query and response messages between the requesting machine and the requested machine), if corresponding The unique identifier is initialized in a similar equivalent local category of the requested machine, and if any required machine reply is true, indicating that the similar equivalent local category has been initialized, then a true result is returned, which is by the isAlreadyLoaded() The method returns, indicating that the local category does not need to be initialized, otherwise a false result is returned, which is returned by the isAlreadyLoaded() method, indicating that the local category must be initialized. Of course, different logic schemes for true or false results can be implemented with the same effect. In addition, the DRT on the local machine may consider a shared record table (possibly on a separate machine (such as Machine X), or a shared and shared record table on each local machine, and updated to maintain substantially the same , or in a database, to determine whether one of the equivalent classes on another machine has been initialized.

If the isAlreadyLoaded() method of DRT 71 returns false, this represents that this category (ie, a plurality of similarly equivalent local categories on the plurality of machines M1...Mn) has not been initialized, and is in the plural The machine M1...Mn is distributed on any other machine in the computing environment, so the execution of the class initialization method is to occur or proceed as this is considered to be a plurality of categories of similar categories on each machine. The first and original initialization. Therefore, when there is a record table shared by one of the initialization states, the DRT must update the initialization state record corresponding to the category in the shared record table to be true or other value to be initialized on behalf of this category, so that by all The machine and subsequent references to the shared record table that includes the initialization state of the current machine (eg, executed by all subsequent firings of the isAlreadyLoaded method) will now return a true value to indicate that the class has been initialized. Therefore, if isAlreadyLoaded() returns false, the modified class initialization routine resumes or continues (or otherwise starts or starts as needed).

On the other hand, if the isAlreadyLoaded method of the DRT 71 returns true, then this represents that the category (each of the plurality of similarly equivalent local categories on one of the plurality of machines M1...Mn) is already in the decentralized environment. It is initialized as if it were recorded on the shared record table on the machine X of the initialization state of the category. In this case, the class initialization method does not execute (or otherwise restart or continue, or start or execute to completion) because it may cause unwanted interactions or contradictions, such as memory, data structures, or other machines. Reinitialization of resources or devices. Therefore, when the DRT returns true, the instruction inserted at the beginning of the <clinit> method prevents the execution of the initialization instance (selectively in whole or in part) by interrupting the use of the return instruction. Starts or resumes the execution of the <clinit> method, and subsequently suspends the initialization of the JAVA virtual machine in this category.

An equivalent procedure for the initialization of the object (e.g., "<init>" method) is illustrated in Figure 21, where steps 212 and 213 are equivalent to steps 202 and 203 of Figure 20. This causes the code in Appendix B3 to be converted into the code in Appendix B4 (see also Table XIII) or Appendix B6 (see also Table XV).

Appendix B3 (see also Table XII) and Appendix B4 (see also Table XIV) are the pre- (or pre-corrected or uncorrected) and/or after (or pre-corrected or uncorrected) of an object initialization example (ie a "<linit>" method) Extracted or corrected code). In addition, another example of another modified <init> method is exemplified in Appendix B6 (see also Table XV). The corrected code added to the method is highlighted in bold text. In the unmodified part of the code example of Appendix B4, the "aload_0" and "invokespecial #3" instructions of the <init> method cause <init> of the java.lang.Object superclass. Next, the next instruction "aload_0" loads a reference to the "this" object onto the stack, becoming one of the arguments to the "8 putfield #3" instruction. Next, the next instruction "invokestatic #2" raises the method java.lang.System.currentTimeMillis() and returns a long value on the stack. Next, the next instruction "putfield #3" writes the long value onto the stack, for the previous "invokestatic #2" instruction to a memory location (field) called "timestamp", which corresponds to The object instance loaded onto the stack by the "4 aload_0" instruction. Therefore, there is no need to manage coordinated object initialization in a distributed environment of the plurality of machines M1, .., Mn, and each has a memory update and transfer means of the 9, 10, 11, 12, and 13 figures, whereby The application code 50 is intended to operate as an example of single coordination, consistency and reconciliation across one of the plurality of machines M1...Mn, each computer or computing machine utilizing multiple implementations corresponding to the <init> method And different values to reinitialize (and optionally rewrite or overwrite) the "timestamp" memory location (field), resulting in the application code 50 on each machine M1,...,M Possible non-harmonic or inconsistent memory between events. It is clear that this is not what a programmer or user of a single application code 50 would expect to happen.

Therefore, with the benefit of DRT, the application code 50 is modified to be loaded into the machine by changing the object initialization instance (i.e., the <init> method). The changes made (in bold) are the initial instructions executed by the modified <init> method. These added instructions determine the initialization state of this particular class by checking whether one of the specific objects on the other machine is equivalent to an equivalent local object, which has been initialized and loaded as needed, by calling An example determines the initialization state of the plurality of similar objects, such as the program or method of "is already loaded" (for example, "isAlreadyLoaded()") in Appendix B7. The "isAlreadyLoaded()" method of the DRT 71 performing steps 172-176 of Figure 17 determines the initialization state of similar equivalent local objects on each machine M1,..., Mn, which corresponds to the loading being performed. The result of the particular object, a "true" result or a "false" result, corresponds to whether another (or more) of the machines M1...Mn have been initialized and loaded as needed. Equivalent objects.

The DRT 71 initialization decision procedure or method "isAlreadyLoaded()" may optionally use an argument that represents a unique identification of the object (see Appendix B6 and Table XV). For example, the object name being considered for initialization is being referenced by one of the objects to be initialized, or represents a unique number or identification across one of the machines (ie, corresponding to one of a plurality of similarly equivalent local categories) The unique identification items, each of which is on the plurality of machines M1...Mn), are used to determine the initialization state of the object of the plurality of identical local objects on each of the machines M1...Mn. In this way, the DRT can simultaneously support the initialization of multiple objects without confusion, because the multiple objects or unloaded ones have been loaded using the unique identifier of each object.

The DRT 71 can have several possible methods to determine the initialization state of the object. Preferably, the requesting machine can sequentially request each of the other required machines (for example, by using a computer communication network to exchange query and response messages between the requesting machine and the requested machine), if corresponding A similarly equivalent local object uniquely identified to the requested machine is initialized, and if any required machine reply is true, indicating that the similar equivalent local class has been initialized, then a true result is returned, which is determined by the isAlreadyLoaded() method Returning, the local object does not need to be initialized, otherwise a false result is returned, which is returned by the isAlreadyLoaded() method, indicating that the local object must be initialized. Of course, different logic schemes for true or false results can be implemented with the same effect. In addition, the DRT on the local machine may consider a shared record table (possibly on a separate machine (such as Machine X), or a shared and shared record table on each local machine, and updated to maintain substantially the same , or in a database, to determine that this particular object (or any of a number of similar equivalents on other machines) has been initialized by one of the required machines.

If the isAlreadyLoaded() method of DRT 71 returns false, then this represents that the object (ie, a plurality of similarly equivalent local objects on the plurality of machines M1...Mn) has not been initialized, and is in the plural The machine M1...Mn is on any other machine in the decentralized computing environment, so the implementation of the object initialization method is to occur or proceed because this is considered the first and the original initialization. Therefore, when there is a record table shared by one of the initialization states, the DRT must update the initialization state record corresponding to the object in the shared record table to be true or other value to represent that the object is initialized, so that by all The machine and subsequent references to the shared record table that includes the initialization state of the current machine (eg, executed by all subsequent firings of the isAlreadyLoaded method) will now return a true value to indicate that the object has been initialized. Therefore, if isAlreadyLoaded() returns false, the modified object initialization routine resumes or continues (or otherwise starts or starts as needed).

On the other hand, if the isAlreadyLoaded() method of the DRT 71 returns true, then this represents that the object (each of the plurality of similarly equivalent local objects on one of the plurality of machines M1...Mn) is already in the dispersion The environment is initialized as if it were recorded on the shared record table on machine X of the object's initialization state. In this case, the object initialization method does not execute (or otherwise restart or continue, or start or execute to completion) because it may cause unwanted interactions or contradictions, such as memory, data structures, or other machines. Reinitialization of resources or devices. Therefore, when the DRT returns true, the instruction inserted at the beginning of the <init> method prevents the execution of the initialization instance (selectively in whole or in part) by interrupting the use of the return instruction. Starts or resumes the execution of the <init> method, and subsequently suspends the initialization of the JAVA virtual machine for this object.

Similar to the fix for <clinit> for <init>. The application's <init> method (or multiple methods, as many may be) is detected, as shown in step 212, and modified, as shown in step 213, to reconcile across the decentralized environment. Local behavior.

The sequence of decoded instructions after the correction has occurred is proposed in Appendix B4 (and another similar configuration is provided in Appendix B6), and the modified/inserted instructions are highlighted in bold. For the <init> fix, unlike the <clinit> fix, the fix instruction often needs to be placed after the "invokespecial" directive, not at the very beginning. This reason is dominated by the JAVA virtual machine specification. Other languages often have similar subtle design differences.

Given the basic notion of testing to determine whether initialization has occurred in a number of similar categories or objects or other assets on one of the machines M1...Mn, and if not, if not, if not, The initialization; there are several different ways or embodiments in which this coordinated and reconciled initialization concept, method, and procedure can be performed or implemented.

In a first embodiment, a particular machine, such as machine M2, loads the asset (e.g., category or object), which includes an initialization routine for modifying it, and then includes an initialization routine containing the new correction. The correction object (or category or other asset or resource) is loaded onto each of the other machines M1, M3, ... Mn (which may be sequential or simultaneous, or according to any other order, exemplification or processing). Please note that there may be one or more instances corresponding to only one object in the application code, or a plurality of instances corresponding to a plurality of objects in the application code. Please note that in a specific embodiment, the initialization routine loaded is a binary executable object code. In addition, the initialization example loaded is an executable intermediate code.

In this configuration, the term "master/controller" can be used, and each controlled (or secondary) machine M1, M3, ... Mn loads the corrected object (or category) and contains A newly modified initialization example sent to the host communication (or primary) machine (eg, machine M2, or some other machine, such as machine X in Figure 15) on the computer communication network or other communication link formula. In some minor changes to this "master/controller" or "primary/secondary" configuration, the computer communication network may be replaced by a shared storage device, such as a shared file system, or a shared File/file storage area, such as a shared database.

Please note that the corrections performed on each machine or computer are not required and often not the same or similar. What is needed is that they are modified in a sufficiently similar manner, and in accordance with the innovative principles described herein, each step of the plurality of machines performs consistently and harmonically for the other machines described herein. Homework and purpose. Furthermore, it will be appreciated from the description provided herein that there are numerous ways in which modifications can be implemented, such as depending on the particular hardware, architecture, operating system, application code, or the like or other factors. It will also be appreciated that embodiments of the present invention may or may not have the benefit of being within an operating system, or within any operating system, within an EPROM, in a software, firmware, or It is implemented in any combination of these.

In another variation of the "master/controller" or "primary/secondary" configuration, machine M2 loads an asset (such as a category or object) containing one (or even one or more) initialization instances. , in uncorrected form on machine M2, and then (for example, machine M2 or each local machine) correct the category (or object or asset) by removing the initialization from the asset (or category or object) in whole or in part For example, the asset's revision code is loaded by a computer communication network or other communication link or path, which has an initialization routine that is now modified or deleted on other machines. Therefore, when the correction is not a conversion, test, translation, or compilation of the asset initialization routine, the initialization routine is deleted on all but one of all machines.

The entire process of deleting the initialization routine may be performed by the "master" machine (e.g., machine M2 or some other machine, such as machine X of Fig. 15) or by each of the other machines M1, M3, ..., Mn. Execute when the uncorrected asset is received. Additional changes to this "master/controlled" or "primary/secondary" configuration are to use a shared storage device, such as a shared file system, or a shared file/archive repository, such as a share A database for exchanging codes of the asset, category or object (including, for example, the modified code) between the machines M1, M2, ..., Mn and the machine X of the selective Fig. 15.

In still other embodiments, each machine M1, . . . , Mn receives the uncorrected asset (eg, category or object), including one or more initialization instances, but corrects the example, and then Enter an asset (such as a category or object) that contains a modified example. While a machine (e.g., the master or primary machine) can customize or perform a different correction to the initialization routine delivered to each machine, this embodiment can immediately make the corrections made by each machine slightly different. And improved, customized, and/or optimized based on its specific machine architecture, hardware, processor, memory, configuration, operating system, or other factors, yet still similar, reconciled, and consistent with all other machines Other similar corrections and features do not necessarily have to be similar or identical.

In another configuration, a particular machine (e.g., M1) loads the uncorrected asset (e.g., category or object), which includes one or more initialization instances, and all other machines M2, M3, ..., Mn Perform an amendment or delete the initial instance of the asset (such as a category or object) and load the modified version.

In all of the specific embodiments described, the asset code (eg, a category code or an object code) is supplied or transmitted to the machines M1, . . . Mn, and a machine X of FIG. 15 is included as needed. Branching, decentralizing or transmitting between any combination or arrangement of different machines; for example by providing direct machine-to-machine communication (eg, supplying each M1, M3, M4, etc. directly from M2), or by providing or using a serial connection Or serial communication (eg, M2 supplies M1, which then supplies M3, then M4, and so on), or the combination of direct and concatenated and/or serial.

In yet another configuration, the initial machine (e.g., M2) can perform an initial loading of the application code 50, modify it according to the invention, and then generate a category/object loading and initialization table listing all or At least all relevant categories and/or objects loaded and initialized by machine M2. This form is then transmitted or delivered (or at least its content is transmitted or delivered) to all other machines (including, for example, in the form of branches or concatenations). Then if a machine (other than M2) needs to be loaded, and thus initializes a category listed in the table, it sends a request to M2 to provide the required information, including the category to be loaded as needed. Or the uncorrected application code 50 of the object or the modified application code of the category or object to be loaded, and optionally initialized for the category or object previously loaded and initialized on machine M2 (or as needed And if available, the latest or even current value or content. Another configuration of this mode is that the requirement to transmit the necessary information is not to machine M2, but to another or even more than one machine M1,..., Mn or machine X. The information provided to the machine Mn is therefore generally different from the initial state loaded and initialized by the machine M2.

In the above circumstances, it is preferred and advantageous for each entry in the table to be accompanied by a counter in which each category or object is loaded and initialized in the machines M1,..., Mn When the middle part is over, it will increase. Therefore, when data or other content is required, the category or object content and the corresponding counter are counted, and the modified or uncorrected application code is included as needed, in response to the demand. This "on demand" mode can increase the burden of implementation of the invention for one or more machines M1,..., Mn, but it also reduces the amount of traffic that interconnects the communication networks of such computers. And therefore provide overall benefits.

In still another configuration, the machines M1 through Mn can transmit some or all of the loading requirements to an additional machine X (see, for example, the specific embodiment of Figure 15), which can perform the correction of the application code 50, Including a (and possibly plural) finalization example, which passes any of the above methods and returns the modified application code, which includes the current modified initialization equation for each machine M1 to Mn, and these machines are The modified application code is loaded in sequence, including a local modified example. In this configuration, machines M1 through Mn transfer all load requests to machine X, which returns a modified application code 50 to each machine, including the modified initialization routine. Such modifications performed by machine X may include any modifications encompassed by the scope of the invention. This configuration can of course be applied to some of the machines and other configurations described herein before being applied to other machines.

Those skilled in the art will be aware of a variety of possible techniques that can be used to modify computer code including, but not limited to, testing, program conversion, translation, or compilation means.

One such technique is to modify the application code without requiring a prior or subsequent change in the language of the application code. Another such technique is to convert the source code (eg, JAVA language source code) into an intermediary representation (or intermediate code language or virtual code), such as a JAVA byte code. Once this conversion occurs, the byte code is corrected and the conversion can be reversed. This provides the results needed for the modified JAVA code.

Another possible technique is to convert the application to machine code, either directly from the source code, or through the aforementioned intermediate language, or through some other intermediary means. The machine code is then corrected before being loaded and executed. Another such technique is to convert the source code into an intermediary representation, thus being modified and subsequently converted to machine code.

The present invention encompasses all of these correction procedures, as well as combinations of two, three or even more such programs.

Finalization

Please return to Figure 14 again, which shows an architectural diagram of a single prior art computer operating as a JAVA virtual machine. In this way, a machine (manufactured by any of a number of manufacturers and having an operating system operating in any of a number of different languages) can operate in a particular language of the application code 50, in this case In the middle of the JAVA language. That is, a JAVA virtual machine 72 is capable of operating the application code 50 in the JAVA language and utilizing a JAVA architecture that is independent of the machine manufacturer and the internal details of the machine.

When implemented in a non-JAVA language or application code environment, the generalized platform, and/or virtual machine, and/or machine, and/or execution time system are capable of operating an application code 50 in the language of the platform. (may include, for example, but not limited to, any one or more of a source code language, a mediation code language, an object code language, a machine code language, and any other code language), and/or a virtual machine, and/or machine, and/or Execute the time system environment and utilize the platform, and/or virtual machine, and/or machine, and/or execution time system, and/or language architecture, regardless of the machine manufacturer and internal details of the machine. It will also be appreciated in the description provided herein that the platform and/or execution time system can include virtual machine and non-virtual machine software and/or firmware architectures, as well as hardware and direct hardware coding applications and implementations.

Moreover, when there is only a single computer or machine 72, the single machine of Figure 14 can easily trace whether the particular object 50X, 50Y and/or 50Z may be the application code at the subsequent time of execution of the application code 50. 50 needs. This can basically be done by maintaining one of the "handle counts" or similar counts or indexes for each object and/or category. This count can basically trace the location or number of times a reference to a particular item (or category) is performed in the application code 50. For a handle count (or other count or index-based implementation) that increments the handle count (or index) when a new reference to the object or category is generated or specified, and when the object or category is destroyed or lost The handle count is reduced downward (or index), and when the object handle count of a particular object reaches zero, there is nowhere to refer to the particular object (or category) in the execution application code 50, wherein the zero Object handle count (or category handle count). For example, in the JAVA language and virtual machine environment, a "zero object handle count" is associated with any reference (zero reference count) that is missing pointing to that particular object. The object is then referred to as "finalizable" or in a finalizable state. The object handle count (and the handle counter) can be maintained for each object in a similar manner, so that the finalizable or non-finalizable state of each particular or particular object can be known. The category handle count (and the category handle counter) can be maintained in a similar manner for each item and each category, so that the finalizable or non-finalizable state of each particular or particular category can be known. Furthermore, asset handle counts or indexes and counters can be maintained in a similar manner for each asset or category and object, so that the finalizable or non-finalizable state of each particular or specific asset can be known.

Once an finalized state has been reached for an item (or category), the item (or category) can be safely finalized. This finalization can basically include the removal (removal, removal, removal, modification, recycling, finalization, or other memory release operation of the item (or category) because the item (or category) is no longer needed.

Therefore, due to the availability of these references, indicators, handle counts, or other categories and object type tracing means, the computer programmer (or other automated or non-automated program generator or means of production) is written using the JAVA language and architecture. The application code 50 program does not require writing any particular code to provide for removal, removal, deletion, modification, recycling, finalization or other memory release operations for this category or item. Because there is only a single JAVA virtual machine 72, the single JAVA virtual machine 72 can track the category and object handles in a consistent, harmonized, and coordinated manner and clean (or finalize) as needed in an automated and unobtrusive manner. For example, unwanted behaviors, errors, immature, redundant or re-finalized jobs are not required, as can be caused by inconsistencies and/or non-harmonic finalization states or handle counts. In a similar manner, a single generalized virtual machine or machine or execution time system can trace the category and object handle counts (or equal if not specified by the "object" and "category"), and if necessary An automated and unobtrusive way to clear (or finalize).

The automated handle counting system described above is used to indicate that an object (or category) of an executing application 50 is no longer needed and may be "deleted" (or cleared, or finalized, or recreated, or recycled, or otherwise). Released separately). It is important to understand the language and architecture implemented in "non-automated memory management" (such as "uncollected garbage" stylized languages such as C, C++, FORTRAN, COBOL and machine code languages such as x86, SPARC, PowerPC , or the mediation code language), the application code 50 or the programmer (or other automated or non-automated program generator or means of production) can make a decision as to when a specific object (or category) is no longer needed, and can be subsequently " Delete" (or clear, or finalize, or recreate, or recycle). Therefore, "deletion" in the context of the present invention is understood to be "non-automated memory management" that is included in the "non-automated memory management" language and architecture corresponding to deletion, finalization, removal, recycling or re-engineering operations. Deletion (or removal, or finalization, or re-creation, or recycling, or release) of an object (or category) in language and architecture.

For a more general combination of virtual machine or abstract machine environments, and for current and future computer and/or computing machines and/or information appliances or processing systems, and which may or may not utilize categories and/or The structure, method, computer program and computer program product of the present invention will still be applicable. Examples of computers and/or computing machines that do not utilize categories and/or objects include, for example, x86 computer architectures manufactured by Intel Corporation and others, SPARC computer architectures manufactured by Sun Microsystems and others, and by IBM Corporation. And the PowerPC computer architecture manufactured by other companies, as well as personal computer products manufactured by Apple Computer and other companies. For these types of computers, computing machines, information appliances, and virtual machines or virtual computing environments that are not implemented using categories or objects, for example, they can be generalized to include basic data types (eg, integer data types). Different, floating point data type, long integer data type, double data type, string data type, symbol data type and Bolling data type), structured data type (such as array and record) Type, or other code or data structure of other procedural languages, or other languages and environments, such as functions, indicators, components, modules, structures, references, and collections.

However, in the configuration illustrated in Figure 8 (also in Figures 31-33), it provides a plurality of individual computers or machines M1, M2, ... Mn, each of which is transmitted through a communication network 53 or Other communication links are interconnected, and each individual computer or machine has a modifier 51 (see Figure 5) and is released, for example, by the Decentralized Execution Time (DRT) 71 (see Figure 8) or Implemented and loaded with a shared application code 50. The term shared application is understood to mean an application or application code written to work on a single machine and loaded and/or executed in whole or in part on the computer or machine M1, M2.. The .Mn is performed in whole or in part, or as needed on the plurality of computers or machines M1, M2...Mn. But somewhat differently, there is a shared application, represented by application code 50, and this single copy or possibly multiple identical copies are modified to produce a modified copy or version of the application or code, each A copy or illustration is prepared to be executed on the plurality of machines. After they are corrected, they are considered to be shared if they perform similar jobs and operate consistently and harmonically. It will be appreciated that a plurality of computers, machines, information appliances, or the like, embodying features of the present invention, may be coupled or coupled to other computers, machines, information appliances, or the like that do not implement the features of the present invention, as desired.

In some embodiments, some or all of the plurality of individual computers or machines may be contained within a single enclosure or enclosure (eg, a so-called blade server, by Hewlett-Packard Development, Intel Corporation, IBM Corporation, and others). Manufactured) either on a single printed circuit board or even in a single wafer or wafer set.

Basically, the corrector 51 or the DRT 71 or other code correction means is responsible for correcting the application code 50, so that it can perform cleaning, or other memory reconstruction, recycling, deletion or finalization in the JAVA language and the virtual machine environment. For example, the finalization method in the JAVA language and virtual machine environment is in a coordinated, consistent and harmonic manner and spans between the plurality of individual machines M1, M2...Mn. It is therefore necessary in this computing environment to ensure that local objects and categories on each individual machine M1, M2...Mn are finalized in a consistent manner (relative to each other).

It will be appreciated that under the description herein, the modifier 51 and the distributed execution time 71 will have additional implementations. For example, the modifier 51 can implement or be within a component of the distributed execution time 71, such that the DRT 71 can implement the functions and operations of the modifier 51. In addition, the function and operation of the corrector 51 can be implemented in addition to the structure, software, firmware or other means for implementing the DRT 71. In a specific embodiment, the modifier 51 and the DRT 71 are implemented or written in a single paragraph of the computer code, and the functions of the DRT and the modifier are provided. Therefore, the modifier function and structure may be included in the DRT and be regarded as an optional component. In addition to how it is implemented, the modifier function and structure is responsible for modifying the executable code of the application code program, and the distributed execution time function and structure is responsible for implementing communication between the computers or machines. The communication functions in a particular embodiment are implemented by an intermediate protocol layer within the computer code of the DRT on each machine. For example, the DRT can implement a communication stack in the JAVA language and use the Transmission Control Protocol/Internet Protocol (TCP/IP) to provide communication or conversation between the machines. In fact, how these functions or operations are implemented or divided between structural and/or procedural elements, or between the computer code or data structure of the present invention, is less important than the ones they provide.

In particular, when the application code executed on a particular machine (eg, machine M3) does not have an active handle, reference, or indicator to a particular local object or category (ie, a "zero handle count"), The same code executed on a machine (eg, machine M5) may have a movable handle, reference or indicator to the local similar equivalent item or category, which corresponds to the "unreferenced" local object or category of machine M3, thus this Other machines (M5) still need to refer to or use the object or category in the future. Therefore, if similar native objects or categories corresponding to each machine M3 and M5 are to be finalized independently and uncoordinated with respect to one of the other machines (which will be cleared by some other memory clearing operation) ), the behavior of the object and the application is not defined as a whole, that is, the lack of coordination, reconciliation, and consistency finalization or memory removal between the machines M1...Mn may cause conflicts or unwanted Interactions, or other anomalous behaviors, such as permanent inconsistencies between similar counterparts on machine M5 and machine M3. For example, if the local similar equivalent item or category on machine M3 is to be finalized, such as deleted, or cleared, or rebuilt, or recycled by machine M3, and in a manner that is uncoordinated and inconsistent with respect to one of machines M5, Then if the machine M5 is to perform a job, or otherwise use a local object or category on the machine M3 that corresponds to a similarly equivalent local object that is now finalized (such jobs are for example in Figures 9, 10, 11, 12, and 13) In the context of a memory update and delivery means, the job (the value of the change or attempt) is written (or attempted to be written) to the machine M5 similar to the equivalent local object or the modification of the value of the particular object) Change) may not be executed (delivered by machine M5) to all other machines M1, M2...Mn, since at least machine M3 will not include specific objects in the local memory that are similarly equivalent, the object and The information, content and values have been deleted by the removal, finalization, or re-engineering or recycling of previous objects. Therefore, even if it is considered that the current machine M5 can write to the object (or category), in fact it has been finalized on the machine M3, which represents that such a writing operation is impossible, or almost on the machine M3. impossible.

In addition, if a category of items on machine M3 is to be marked as finalizable and subsequently finalized (eg, by deletion, or removal, or reconstitution, or recycling), the same on other machines M1, M2...Mn The object is also not marked as finalizable, and the finalization (or deletion, or removal, or re-engineering, or recycling) of the object on machine M3 is coordinated with respect to all machines M1, M2...Mn. The finalization operation is immature, as machines other than M3 have not been prepared to finalize their local equivalents corresponding to special items that are now finalized or finalizable by machine M3. Thus, if machine M3 is to perform a purge or other finalization on a given particular item (or category), the purge or other finalization instance will perform the cleanup or finalization, not just on machine M3. Local object (or category), but also for all similar local objects or categories on all other machines (ie corresponding to special items or categories to be cleared or otherwise finalized).

If these conditions are to occur, the behavior of equivalent objects on other machines M1, M2...Mn is undefined and may result in permanent and irreversible inconsistency between machine M3 and machines M1, M2...Mn. Sex. Thus, although machine M3 can independently determine that an item (or category) has been finalized and finalize the specified item (or category), machine M5 may not be the same equivalent local object that has been prepared for finalization. (or category) make the same decision, so inconsistent behavior may result from the deletion of one of a number of similar objects on a machine (eg machine M3), but not on other machines (eg machine M5) Or a plurality of machines, and the finalized version of the specified object (or category) is performed immaturely by machine M3 and represents all other machines M1, M2...Mn. The minimum operation of machine M5 and other machines in the above-mentioned conditions are unpredictable and may result in inconsistent results. Such inconsistency may come, for example, from immature execution of the finalization and/or A machine or a subset of some machines but does not delete the object on other machines. Therefore, it will not be possible to achieve a coordinated finalization (or other memory clearing operation) required to achieve or provide consistency for the synchronization of the same application code on each of the plurality of machines M1, M2...Mn. ). Therefore, any attempt to maintain the same memory content and the memory update and transmission means of Figures 9, 10, 11, 12 and 13 or even the same memory content, as a special or defined category, object, The combination of numerical values or other data for each machine M1, M2, ..., Mn, for the simultaneous operation of the same application, will not be achieved for a given utility.

In order to ensure a consistent category and object (or equivalent) finalization status and finalization or removal between machines M1, M2, ..., Mn, the application code 50 is searched for the entire executable application code 50. Analysis or scrutiny to detect program steps (eg, specific instructions or types of instructions) in the application code 50 that may define or constitute or otherwise represent a finalized job or modality (or other similar memory, Data or code removal routines, or other similar re-engineering, recycling, or deletion operations). In the JAVA language, these program steps include, for example, or a "finalize()" method of some or all of an object, and any other code, instance or method associated with a "finalize()" method, as needed or The method, for example, evokes a different method by the subject of the "finalize()" method.

This analysis or scrutiny will occur before the application code 50 is loaded, or during the application code 50 loading process, or even after the application code 50 loads the program. It can be similar to an installation, program conversion, translation, or compilation program, where the application can be implemented with additional instructions, and/or can be modified by meaning retention program manipulation, ie, or alternatively by an input code language. Translating into a different code language (for example, translation from source code or mediation code language to machine language), and knowing that the term compilation usually or customally contains changes in the code or language, such as by source code or object code , or from one language to another. However, in this example the term "compilation" (and its grammatical equivalents) is not so limited and may include or contain amendments within the same code or language. For example, the compilation and its equivalents can be understood to include both normal compilation (eg, by way of illustration and not limitation, from source code to object code), and compiled from source code to source code, and compiled from object code to object. The code, and any combination of any of them. It may also include a so-called "intermediary language" in the form of "virtual object code".

By way of illustration and not limitation, in one embodiment, analysis or scrutiny of the application code 50 may occur during loading of the application code, such as by the operating system from the hard disk or other storage device or source. The application code is read, copied to memory, and ready to begin execution of the application code. In another embodiment, in a JAVA virtual machine, the analysis or scrutiny can occur during a class loader of the java.lang.ClassLoader loadClass method (eg, java.lang ClassLoader.loadClass()).

In addition, the analysis or scrutiny of the application code 50 can occur even after the application code loading program, for example, after the operating system has loaded the application code into the memory, or alternatively even in the application code. After the relevant part has been started or carried out, for example, after the JAVA virtual machine has loaded the application code into the virtual machine, it passes the "java.lang.ClassLoader.loadClass()" method, and Execute selectively.

Therefore, in the above analysis or scrutiny, the initial system looks for a clearing example, and when it is found or recognized, inserts a correction code to call a modified clearing example. This modified example is adapted and written to suspend the clearing modality on any particular machine, unless a category or object is to be deleted, removed, recreated, recycled, released, or otherwise finalized (or more generally The words "assets" are marked as being deleted by all other machines. There are several different modes in which this correction and loading can be done.

By way of illustration and not limitation, in one embodiment, analysis or scrutiny of the application code 50 may occur during loading of the application code, such as by the operating system from the hard disk or other storage device or source. The application code is read, copied to memory, and ready to begin execution of the application code. In another embodiment, in a JAVA virtual machine, the analysis or scrutiny may occur during execution of the java.lang.ClassLoader loadClass method (eg, java.lang.ClassLoader.loadClass()).

In addition, the analysis or scrutiny of the application code 50 can occur even after the application code is loaded into the program, for example, the operating system has loaded the application code into the memory, or even started execution, or in the java virtual machine. After the application code has been loaded into the virtual machine via the "java.lang.ClassLoader.loadClass()" method. In other words, in the example of the JAVA virtual machine, it has been determined after executing "java.lang.ClassLoader.loadclass()".

So in one mode, the DRT 71/1 on the load machine, in this case the Java Virtual Machine M1 (JVM#1), requires all other machines M2,..., Mn DRT's 71/2. ..71/n, if similar equivalent first category 50X, if used, referenced or used by any other machine M2,...Mn (ie not marked as finalized). If the answer to this question is yes (that is, if a similar object is being used by another machine or multiple machines and is not marked as finalizable, it will not be deleted, cleared, finalized, recreated , Recycle or Release), the normal clearing case is turned off, aborted, paused, or otherwise disabled for the equivalent first object 50X on machine JVM #1. If the answer is no (ie, on each machine similar to the first object 50X is marked on all other machines to be finalized with a similar equivalent 50X), then the clearing instance is manipulated (or restarted) Or continuing, or proceeding, and the first item 50X and a similar equivalent item 50X are deleted not only on the machine JVM #1 but on all other machines M2...Mn. Preferably, the execution of the clearing routine is configured for a machine, for example, the last machine M1 indicates that the similar equivalent item or category is finalizable. The execution of the finalized embodiment corresponds to the plurality of similar equivalents determined by all machines being finalizable, which corresponds to all machines M1...Mn only once, and preferably only by one machine To represent all machines M1...Mn. Corresponding to, and preferably in accordance with, the execution of the finalized embodiment, all machines may delete, recreate, recycle, release or otherwise erase the memory (and other corresponding system resources) used by their local similar equivalents.

Appendix C1, C2, C3 and C4 (also partially reproduced in Tables XVI, XVII, XVIII and XIX below) are exemplary code list columns that provide a finalized example of one of the applications 50 (Appendix C1 and Table) XVI) The conventional or unmodified computer program software code (for example, which can be used in a single machine or computer environment), and a post-correction excerpt of the same synchronization example, such as a specific embodiment with multiple machines that can be used in the present invention Medium (Appendix C2 and C3 and Tables XVII and XVIII). At the same time, the modified code added to the initialization example is emphasized in bold text.

Appendix C1 is an excerpt from the pre-correction of the compiled form of the decoding of the finalize() method of the example.java application of Appendix C4. Appendix C2 is the revised form of Appendix C1, which is corrected by the procedure of Figure 22 using FinalLoader.java in Appendix C7. Appendix C3 is another post-correction form of Appendix C1, which is modified by the procedure of Figure 22 in Final Loader.java of Appendix C7. These corrections are highlighted in bold.

Appendix C4 is an excerpt of the source code of the example.java application used in the excerpts C1-C3 before/after the correction. This example application has a single finalization example that is modified according to the present invention by FinalLoader.java of Appendix C7.

It should be noted that the compiled code in the appendix and the part in the form repeated in the table are in the form of the file "example.java", which is included in Appendix C4. In the procedures of Appendix C1 and Table XVI, the program name "Method finalize()" of step 001 is the name of the decoded output of the display of the finalization method of "example.java" compiled with the application code. The method name "finalize()" is the name of the finalization method of the object according to one of the JAVA platform specifications, and this example is selected to represent a typical mode of the operation of a JAVA final method. Overall, the method is responsible for configuring system resources or performing other cleanups corresponding to the garbage collector that determines the JAVA virtual machine that does not have a reference to the object, and the code executed by the "example.java" is described in order. .

First (step 002), the JAVA virtual machine instruction "getstatic #9<Field java.io.PrintScream out>" causes the JAVA virtual machine to retrieve the second of the classfile structure stored in the application containing the sample finalize() method. The object reference of the static field indicated by the CONSTANT_Fieldref_info constant_pool item in the index, and causes the reference to the java.io.PrintStream object in the field to be placed (pushed) in the current method frame of the currently executing thread On the stack.

Next (step 003), the JAVA virtual machine instruction "ldc #24<String"Deleted...">" causes the JAVA virtual machine to load the string value "Deleted" onto the stack of the current method frame, and Causes the string value "Deleted" to be loaded to the top of the stack of the current method frame.

Next (step 004), the JAVA virtual machine instruction "invokevirtual #16<Method void println(java.lang.String)>" causes the JAVA virtual machine to push out the stack of the top method frame leaving the current method frame and cause the The "println" method sends the launched item to the new method frame as its first argument and causes the "println" method to be fired.

Finally, the JAVA virtual machine instruction "return" (step 005) causes the JAVA virtual machine to stop executing the finalize() method by returning control to the previous method frame, which causes the termination of execution of the finalization method. .

Due to these steps being performed on a single machine of the conventional configuration in Figures 1 and 2, the JAVA virtual machine can track the object handle count in a consistent, harmonic, and coordinated manner, and execute the println containing the println The job's finalize() method guarantees that unwanted behavior will not occur (such as immature or excessive number of finalization jobs, such as performing a single 'example.java' object's finalize() method more than once), for example by inconsistency And/or not reconciling the finalized state or the handle count. If these steps are to be performed on a plurality of machines in the configuration of Figures 5 and 8, and have the memory update and transfer copying means of Figures 9, 10, 11, 12 and 13, and synchronized in the complex part The application code 50 is executed on each of the machines M1...Mn, and the finalization of each synchronized application event on each machine will be on any other machine, without any other events. Coordination can be done. Given the goal of finalization of consistency, coordination, and reconciliation across multiple machines, this prior art configuration will not be able to perform this consistent, coordinated finalization of operations across the complex machine, as each The machine performs finalization only locally and does not attempt to coordinate their local finalization jobs with any other similar finalization jobs on any other machine or machines. This configuration will therefore be subject to unwanted or other anomalous behavior due to uncoordinated, inconsistent and/or non-harmonized finalized states or handle counts and associated finalization operations. It is therefore an object of the present invention to overcome the limitations of prior art configurations.

In the sample code of Table XVIII (Appendix C3), the code has been corrected, so it solves the consistency and coordination of the complex machines M1...Mn that cannot be solved in the code example of Table XVI (Appendix C1). The problem of finalizing the job. In the corrected finalize() method code, an "aload_0" instruction is inserted before the "getstatic #9" instruction, and is the first instruction of the finalize() method. This causes the JAVA virtual machine to load the project into the local variable array at index 0 of the current method frame and store the item above the stack of the current method frame and make the "this" at index 0 The object in the object reference of the object is pushed onto the stack.

Furthermore, the JAVA virtual machine instruction "invokestatic #3<Method boolean isLastReference(java.lang.Object)>" is inserted after the "0 aload_0" instruction, so the JAVA virtual machine launches the topmost item leaving the current method. The stack of frames (which refers to the object to which the finalize() method belongs according to the previous "aload_0" instruction), and raises the "isLastReference" method, transmitting the launched item to the new method frame as its first The argument, and returns a Boolean value to the stack in this "invokestatic" instruction. This change is obvious because it corrects the finalize() method to execute the "isLastReference" method and related jobs, corresponding to the start of execution of the finalize() method, and returns a Boolean argument (representing whether to apply The category of the finalize() method is on the stack of execution method frames of the finalize() method on each machine of the plurality of machines M1...Mn, similar to the last remaining reference between the equivalent objects.

Next, two JAVA virtual machine instructions "ifne 8" and "return" are inserted into the code stream after the "1 invoke static #3" instruction and before the "getstatic #9" instruction. The first of these two instructions is the "ifne 8" instruction, which causes the JAVA virtual machine to push the topmost item out of the stack and perform a comparison between the pushed value and zero. If the comparison of the execution is successful (ie if and only if the pushed value is not equal to zero), then execution continues to the "8 getstaticw #9" instruction. But if the comparison of the execution fails (i.e. if and only if the pushed value is not equal to zero), execution proceeds to the next instruction in the code stream, which is the "7 return" instruction. This change is particularly noticeable because it corrects the finalize() method to continue executing the finalize() method (ie, instructions 8-16) when the return value of the "isLastReference" method is positive (ie, "true"). Or when the "isAlreadyLoaded" method is negative (ie "false"), the execution of the finalize() method is interrupted (ie the "7 return" instruction causes the return control to be caused by the finalize() method) .

The method void isLastReference (java.lang.Object), part of the Final Client code of Appendix C5, and part of the Decentralized Execution Time System (DRT) 71, which performs communication operations between the machines M1...Mn, Coordinate the execution of the finalize() method between the machines M1...Mn. The isLastReference method of this example transmits the InitServer code of Appendix C6 executed on machine X of Figure 15, by transmitting a "clear status request" to the machine X corresponding to the object being "finalized" (ie, this The category to which the finalize() method belongs). Referring to Figure 25 and Appendix C6, Machine X receives the "Clear Status Requirement" corresponding to the object to which the finalize() method belongs, and causes a table to clear the count or finalize state to determine the object corresponding to the request. Clear the count or finalize the status.

If the plural equivalent similar item on each of the plurality of machines M1...Mn corresponding to the purge state requirement is marked as all but the required machine (i.e., n-1 machine) On the clear, machine X will send a response to indicate that the plurality of similar objects are marked as cleared on all other machines, and update the record entry corresponding to one of the specified equivalent objects as needed to represent the Similar equivalents are now cleared. In addition, if the plurality of similar objects corresponding to the purge status requirement are not cleared on all other machines except the required machine (ie, less than the n-1 machine), machine X will transmit a response to represent the plural. A similar equivalent is not marked as clear on all other machines, and a "marked as clear counter" record (or other similar finalized recording means) corresponding to the specified item is added to record that the requested machine has been marked One of these multiple equivalent objects to be cleared. Corresponding to the equivalent object corresponding to the determination of the clearing state requirement, that is, all the machines except the required machine are cleared, that is, a reply is generated, and transmitted to the requesting machine to represent the plurality of similar Equivalent items are marked as cleared on all other machines except the required machine. Additionally and optionally, machine X may update the entry corresponding to the item associated with the purge status request to represent that the plurality of similar items are now "cleared". After receiving such a message from machine X, the plural equivalent object is marked as cleared on all machines, the isLastReference() method and the job are terminated, and a 'true' value is returned to the previous Method frame, which is the execution method frame of the finalize() method. In addition, after receiving a message from machine X, it means that the plurality of similar objects are not marked as cleared on all other machines, the isLastReference() method and the job are terminated, and a 'false' is returned. The value is passed to the previous method frame, which is the execution method frame of the finalize() method. After returning the job here, the implementation of the finalize() method frame is then restarted, as indicated in the code sequence in Appendix C3 of the step.

It will be appreciated that the modified code allows for the finalization of the coordination of the routine or other cleaning operations in a distributed computing environment having a plurality of computer or computing machines, so that the machine M1...Mn in the complex part Problems with the work of an uncorrected code or program (such as, for example, an error, immature, multiple finalization, or re-finalization) do not occur when the modified code or program is applied.

It can be observed that the codes in Appendix C2 and Table XVII are another option, but are inferior to the code in Appendix C3. Basically it is functionally equivalent to the codes and methods in Appendix C3.

As can be seen from Fig. 15, the modification of the general configuration of Fig. 8 provides that the machines M1, M2...Mn are as before, and perform the same simultaneously or synchronously on all machines M1, M2...Mn The application code is 50 (or many codes). However, the previous configuration was modified by the provision of a server machine X, which was convenient to be able to supply housekeeper functions, such as, in particular, the removal of structures, assets and resources. This server machine X can be a low value commercial computer, such as a PC, because of its low computational load. As indicated by the dashed lines in Figure 15, the two server machines X and X+1 can be provided for redundancy purposes to increase the overall reliability of the system. When both server machines X and X+1 are provided, they are preferably operated as redundant machines in a non-failed environment.

It does not need to provide a server machine X because its computational load can be spread over the machines M1, M2...Mn. In addition, a database operated by a machine (in a master/controlled class job) can be used for housekeeping functions.

Figure 16 shows a preferred general procedure to follow. After the load 161 is performed, the instructions to be executed are considered to be in the sequence, and all of the clearing instances are detected as shown in step 162. In the JAVA language, these are the finalization or finalization methods (such as finalize()). Other languages use different terms.

When a clearing pattern is detected, it is modified in step 163 to perform a clearing or finalization of consistency, coordination, and reconciliation between the plurality of machines M1, M2...Mn, which is substantially By inserting additional instructions into the cleanup routine, for example, to determine if an object (or class or other asset) containing this finalized formula is marked as being able to be finalized across all similar native objects on all other machines. And if so, the finalization is performed by restarting execution of the finalization example, or if not, suspending execution of the finalization instance, or delaying or suspending execution of the finalization instance until All other machines have been marked as being equivalent to equivalent local objects for finalization. Additionally, the modified instructions can be inserted before the example. Once the correction has been completed, the loader continues by replacing the uncorrected application code with the modified application code, as shown in step 164. At the same time, the finalization example is only to be executed once, and preferably all machines M1...Mn are represented by only one machine, which corresponds to the determination of the specific object by all the machines M1...Mn. Finalized.

Figure 17 shows a specific form of correction. First, the structures, assets or resources (categories or objects in JAVA terminology) 50A, 50X...50Y, which are potential candidates that are cleared, are configured with a name or label (eg a generic name or label) ), or have been configured with a generic name or label that can be used to identify corresponding similar local structures, assets or resources (eg categories and objects in JAVA) common to each machine M1, M2...Mn Above, as shown in step 172. This preferably occurs when the categories or objects are originally initialized. This is most conveniently accomplished by a form maintained by the server machine X. This form also includes the "Clear Status" for that category or item (or other asset). It will be appreciated that this form or other data structure may only store the clear status, or it may store other status or information. In a specific embodiment, the form also includes a counter that stores the number of machines that identify the particular item, category, or other asset that has been identified for deletion (and, if desired, the identification of the machines, although it is not need). In a specific embodiment, the count value is increased until the count value is equal to the number of machines. Therefore, when the entire machine asset deletion count value is less than (n-1), where n is the total number of machines in Mn, which represents the object, category, or other asset as a network (or machine cluster) as a whole. State, because the machine asset deletion count less than n-1 represents that one or more machines have not been marked with similar equivalent local objects (or categories or other assets) to be finalized, and the object cannot be cleared because it does not cause To be or other unusual behavior. In different narratives, and by way of example (but not by way of limitation), if there are six machines and the asset deletion count is less than five, it represents that not all other machines have attempted to finalize the object (ie, the object is not marked as being Finalized), and therefore the object cannot be finalized. However, if the asset deletion count is five, it means that only one machine has not yet attempted to finalize the object (ie, the object is marked as finalizable), so the machine that has not yet marked the object as finalizable must be an attempt. The current machine that finalizes the item (ie, indicates that the item is finalizable, and thus causes the finalized form to be the finalized state of the item on all other machines). In the configuration of the six machines, the count value of n-1=5 represents that the five machines must have previously marked the object as deleted, and the sixth machine to mark the object as deleted is actually performing the complete finalization. Example machine.

As shown in Figure 17, if the generic name or identification is on all other machines (ie, all machines except the one that is to be cleared or deleted) is not marked as cleared or deleted or otherwise finalized. , then the purge or finalization stipulated by the object or category (or other asset) must be aborted, stopped, suspended, suspended, delayed, or cancelled before its initialization, or if it has been initialized, it is completed. If it has already begun execution, since the object or category is still required by one or more machines M1, M2...Mn, as shown in step 175.

In a specific embodiment, the cleanup or finalization instance is either initialized or begins to execute; however, in some implementations it is difficult or practically impossible to stop the cleanup or finalize the initialization or start execution. . Thus, in another embodiment, the execution of the finalized example that has begun is aborted such that it does not complete or does not complete in its normal manner. This additional suspension can be understood to include an actual interruption, or a suspension, or a delay, or a suspension of the execution of the finalization of the execution (regardless of the execution phase prior to completion), thus ensuring the finalization The example does not have an opportunity to execute to complete the removal of the item (or category or other asset), and therefore the item (or category or other asset) remains "not cleared" (ie "not finalized" or "not delete").

But or in addition, if a common name or other unique number or identification of a plurality of similarly equivalent local items in each of the plurality of machines M1, M2...Mn is marked as deleted on all other machines, This means that no other machine needs a category or object (or other asset) that corresponds to the generic name or other unique number or identification. The conditions specified in step 176 may and must be performed as a result of clearing routines and operations, or routinely clearing routines and operations as needed.

Figure 18 shows a query made by the machine (M1, M2...Mn) for performing a clearing example for the server machine X. The job of the proposed machine is temporarily interrupted, as shown in steps 181 and 182, and corresponds to step 173 of FIG. In step 181, the proposing machine transmits a query message to machine X to request that the purge or finalization state of the object (or category or other asset) be cleared. Next, the requesting machine waits for a reply from machine X corresponding to the query message transmitted by the requesting machine in step 181, as shown in step 182.

Figure 25 shows the activity performed by machine X in response to such a finalization or clear status query of step 181 of Figure 18. The final or clear state decision is as shown in step 192, which may determine if the object (or category or other asset) corresponding to the purge status requirement of the generic name, ie, the recipient in step 191 (191A), is marked as All other machines except the query machine 181 required to initiate the clear state of step 191 are deleted. The single term object or category (or equivalent of the asset or resource used in step 191 (192A) or other drawings) used in this document can be understood to include the corresponding machine M1, M2 in the complex machine. , ... all similar equivalents (or categories, or assets or resources) of the same generic name on each of Mn. If the decision of step 193 (193A) is to determine that the universally named resource is not marked ("No") as being deleted on the (n-1) machine (ie, used elsewhere), then the response to the effect is transmitted to The query machine 194 (194A), but the "marked as delete" counter is incremented by one, as shown in step 197 (197A). Similarly, if the answer to this decision is marked as ("Yes"), which represents the universally named resource, ie, deletes all other machines except the waiting query machine 182, a corresponding reply is sent to the wait. The machine 182 is queried from the clear state requester of the start step 191 as shown in step 195 (195A). The wait query machine 182 can then respond accordingly, such as by (i) aborting (or pausing, or delaying) the finalization of the instance, when the reply representative from machine X of step 182 corresponds to the proposed The similarly equivalent local objects on the plurality of machines M1, M2, ... Mn of the generic name of the object that was finalized in step 172 can still be used elsewhere (ie, except for the machine that is to be finalized) All other machines are not marked as deleted; or (ii) by continuing (or restarting, or starting) the finalization example, when the reply from machine X of step 182 indicates that the representative corresponds to the proposed step The equivalent local objects on the plurality of machines M1, M2, ... Mn of the general name of the object that was finalized in 172 are not used elsewhere (i.e., for all but the machine proposed for finalization) The machine is marked as deleted). As indicated by the dashed line in Fig. 25, it is preferable that the state of the shared form or the clearing stored or maintained on the machine X is updated in addition to the "yes" response shown in step 195, so the general purpose The state of the named asset is changed to "Clear", as shown in step 196.

Please refer to Appendix C attached, where: Appendix C1 is a typical code paragraph from an uncorrected finalization example, Appendix C2 is the equivalent of a finalized version of a revision, and Appendix C3 is for a correction. The other equivalent of the finalized formula.

Appendices C1 and C2/C3 in Tables XVI and XVII/XVIII are respectively excerpted from the previous (pre-corrected or uncorrected) and subsequent (or later corrected or corrected) extracts of a finalized version. The corrected code added to the method is highlighted in bold text. In the source code example of Appendix C1, the finalization method prints "Deleted..." to the computer console in the event of finalization (ie, deletion) of the object. Thus, without the finalization of objects managed in a decentralized environment, each machine will re-finalize the same object, so a single universally named reconciliation of multiple equivalent objects will perform more than one finalization method. It is clear that this is not what a programmer or user of a single application code is expected to happen.

Therefore, with the benefit of DRT, the application code 50 is modified to be loaded into the machine by changing the clear, delete, or finalized instance or method. It will be appreciated that the terminating of the term is basically used in the context of the JAVA language relative to the JAVA virtual machine specification when it is dated on the filing date of this description. Therefore, finalization is a more general understanding of the removal or deletion or re-creation or recycling of objects and/or categories or the removal of any equivalent form of object, category, asset or resource. The terminology is finalized and must therefore be used in this broad sense unless otherwise limited. The changes made (in bold) are the initial instructions executed by the finalization method. These added instructions check whether the particular object is the last remaining object of the plurality of equivalent objects on the plurality of machines M1, M2...Mn to be finalized, by calling a case. The cleared state of the object to be finalized, such as the "isLastReference()" program or the DRT 71 method, which performs steps 172-176 of Figure 17, in which a decision is made regarding the clear state of the particular object, and which determines A true result or a false result corresponding to a particular object on the particular machine that is executing the decision procedure is the last of the plurality of machine M1, M2...Mn, each having a similar One of the outlet objects is required to finalize. Recall that a mesh object represents a similar object on a different one of the machines, so for example in a configuration with eight machines, there will be eight dot objects (ie on each of the eight machines) There are eight similar equivalents).

The finalization decision procedure or method of the DRT 71 "isLastReference()" may optionally employ an argument that represents a unique identifier for the object (see Appendix C3 and Table XVIII). For example, the name of the object being considered for finalization, a reference to the object being questioned, or the object that spans all machines (or nodes) to be used to determine the object or category or other asset. A unique number or identification of the finalized state. In this way, the DRT can simultaneously support the finalization of multiple objects (or categories or assets) without confusion, since the multiple objects have been or have not been finalized, and have been considered using the unique identification of each object. See the correct record in the finalized form earlier.

The DRT 71 can have several possible methods to determine the finalized state of the object. Preferably, it (the requesting machine) can sequentially request each of the other required machines (for example, by using a computer communication network to exchange query and response messages between the requesting machine and the requested machine), If their equivalent equivalents of the machine have been marked as finalized, and if any required machine response is false, ie, similar equivalents representing them are not marked as finalized, a false result is returned, which The isLastReference() method returns, indicating that the local object does not need to be finalized, otherwise a true result is returned, which is returned by the isLastReference() method, indicating that the local object must be finalized. Of course, different logic schemes for true or false results can be implemented with the same effect. In addition, the DRT 71 on the local machine may consider a shared record table (possibly on a separate machine (such as Machine X), or a shared and shared record table on each local machine, and updated to maintain substantial The same, or in a database, to determine whether each of the plurality of objects has been marked as being finalized except for all required machines other than the currently required machine.

If the "isLastReference()" method of the DRT 71 returns true, then this means that the object has been finalized for all other machines (ie, the plurality of machines M1...Mn) in the virtual or decentralized computing environment. Therefore, the execution of the finalization method is carried out in consideration of the fact that the last equivalent equivalent items on the plurality of machines M1, M2...Mn are to be marked or declared finalizable.

On the other hand, if the "isLastReference()" method of the DRT 71 returns false, then this means that the plurality of similar objects have not been marked as finalized for all other machines in the distributed environment, such as the finalized state of the object. The person recorded in the shared record table on machine X. In this case, the finalization method is not to be executed (or otherwise restarted or continued) because it will probably invalidate objects on those machines, which are to continue to use them like equivalents and have not yet labeled them. Similar equivalents are finalized. Therefore, when the DRT returns false, the four instructions inserted at the beginning of the finalization method can prevent the remaining code of the finalization method from being executed, by suspending execution of the finalization method by using a return instruction. Then the finalization of the Java virtual machine for this object is aborted.

The basic idea of a given test is to decide if a finalization (like a deletion or removal) is already made on a category, object or other asset; and if the finalization is to be done, and if not prepared, then Finalization will occur, ie there are several different methods or specific embodiments in which this finalization concept, method and procedure can be implemented.

In a first embodiment, a particular machine, such as machine M2, loads the asset (e.g., category or object), which includes a clearing example that corrects it, and then loads the corrected object (or category or asset) into M1, M3, ... Mn on each of the other machines (which may be sequential or simultaneous, or according to any other order, exemplification or procedure). Please note that there may be one or more instances corresponding to only one object in the application code, or a plurality of instances corresponding to a plurality of objects in the application code. Please note that in a particular embodiment, the cleanup example loaded is a binary executable object code. In addition, the clearing example loaded is an executable intermediate code.

In one configuration, the term "master/controller" (or primary/secondary) may be used, and each controlled (or secondary) machine M1, M3, ... Mn loads the modified object (or category), and is included in the computer communication network or other communication link sent by the master (or main) machine (such as machine M2, or some other machine, such as machine X in Figure 15) Its new revised memory manipulation job. In some minor changes to this "master/controller" or "primary/secondary" configuration, the computer communication network may be replaced by a shared storage device, such as a shared file system, or a shared File/file storage area, such as a shared database.

Please note that the corrections performed on each machine or computer are not required and often not the same or similar. What is needed is that they are modified in a sufficiently similar manner, and in accordance with the innovative principles described herein, each step of the plurality of machines performs consistently and harmonically for the other machines described herein. Homework and purpose. Furthermore, it will be appreciated from the description provided herein that there are numerous ways in which modifications can be implemented, such as depending on the particular hardware, architecture, operating system, application code, or the like or other factors. It will also be appreciated that embodiments of the present invention may or may not have the benefit of being within an operating system, or within any operating system, within an EPROM, in a software, firmware, or It is implemented in any combination of these.

In another variation in the "master/controller" or "primary/secondary" configuration, machine M2 loads the asset (eg, category or object), including a cleanup of the uncorrected form on machine M2. For example, then (for example, M2 or each localization machine) deletes the uncorrected cleanup modality that is already present on the machine, either in whole or in part from the asset (eg, category or object), and borrows A correction code for the asset is loaded by a computer communication network that utilizes a clearing of new corrections or deletions on other machines. Therefore, in this case, when the correction is not a conversion, test, translation or compilation of the asset clearing example, the initialization routine is deleted on all but one of all machines. In a specific embodiment, the actual code block of the finalized or cleared instance is deleted except for one of all machines, and thus the last machine is the only machine that can execute the finalized example, since all The finalization example has been removed by other machines. The benefit of this approach is that there is no conflict between multiple machines that perform the same finalization example, as only one machine has this example.

The entire process of deleting the clearing instance may be performed by the "master" machine (e.g., machine M2 or some other machine, such as machine X of Fig. 15) or by each of the other machines M1, M3, ..., Mn. Execute when the uncorrected asset is received. Additional changes to this "master/controlled" or "primary/secondary" configuration are to use a shared storage device, such as a shared file system, or a shared file/archive repository, such as a share A database for exchanging codes of the asset, category or object (including, for example, the modified code) between the machines M1, M2, ..., Mn and the machine X of the selective Fig. 15.

In still other embodiments, each machine M1, . . . , Mn receives the uncorrected asset (eg, category or object) containing one or more finalized or cleared instances, but corrects the example And then load the asset (such as a category or object) that contains the example that is now fixed. While a machine (e.g., the master or primary machine) can customize or perform a different correction to the finalization or removal routine delivered to each machine, this particular embodiment can be immediately made by each machine. The fixes are slightly different and are improved, customized, and/or optimized based on their specific machine architecture, hardware, processor, memory, configuration, operating system, or other factors, yet still similar, reconciled, and other machines Consistent with all other similar corrections and features, they need not necessarily be similar or identical.

In another configuration, a particular machine (such as M1) loads the uncorrected asset (eg, category or object), which includes one or more finalization or cleanup instances, and all other machines M2, M3, .. .Mn performs a correction or deletion of the asset's cleanup instance (such as a category or object) and loads the modified version.

In all of the specific embodiments described, the asset code (eg, a category code or an object code) is supplied or transmitted to the machines M1, . . . Mn, and a machine X of FIG. 15 is included as needed. Branching, decentralizing or transmitting between any combination or arrangement of different machines; for example by providing direct machine-to-machine communication (eg, supplying each M1, M3, M4, etc. directly from M2), or by providing or using a serial connection Or serial communication (eg, M2 supplies M1, which then supplies M3, then M4, and so on), or the combination of direct and concatenated and/or serial.

In yet another configuration, the machines M1 through Mn can transmit some or all of the loading requirements to an additional machine X (see, for example, the specific embodiment of Figure 15), which can perform an amendment to the application code 50 ( For example, including assets, and/or categories, and/or objects, including finalization or removal routines, by any of the above methods, and returning the modified application code, including for each machine M1 to Mn Corrected finalization or cleanup routines, and these machines sequentially load the modified application code, which includes a local modified example. In this configuration, machines M1 through Mn transfer all load requests to machine X, which returns a modified application code 50 to each machine, including a modified finalization or clearing routine. Such modifications performed by machine X may include any modifications encompassed by the scope of the invention. This configuration can of course be applied to some of the machines and other configurations described herein before being applied to other machines.

Those skilled in the art will be aware of a variety of possible techniques that can be used to modify computer code including, but not limited to, testing, program conversion, translation, or compilation means.

One such technique is to modify the application code without requiring a prior or subsequent change in the language of the application code. Another such technique is to convert the source code (eg, JAVA language source code) into an intermediary representation (or intermediate code language or virtual code), such as a JAVA byte code. Once this conversion occurs, the byte code is corrected and the conversion can be reversed. This provides the results needed for the modified JAVA code.

Another possible technique is to convert the application to machine code, either directly from the source code, or through the aforementioned intermediate language, or through some other intermediary means. The machine code is then corrected before being loaded and executed. Another such technique is to convert the source code into an intermediary representation, thus being modified and subsequently converted to machine code.

The present invention encompasses all of these correction procedures, as well as combinations of two, three or even more such programs.

Synchronization

Please return to Figure 14 again, which shows an architectural diagram of a single prior art computer operating as a JAVA virtual machine. In this way, a machine (manufactured by any of a number of manufacturers and having an operating system operating in any of a number of different languages) can operate in a particular language of the application code 50, in this case In the middle of the JAVA language. That is, a JAVA virtual machine 72 is capable of operating the application code 50 in the JAVA language and utilizing a JAVA architecture that is independent of the machine manufacturer and the internal details of the machine.

When implemented in a non-JAVA language or application code environment, the generalized platform, and/or virtual machine, and/or machine, and/or execution time system are capable of operating an application code 50 in the language of the platform. (may include, for example, but not limited to, any one or more of a source code language, a mediation code language, an object code language, a machine code language, and any other code language), and/or a virtual machine, and/or machine, and/or Execute the time system environment and utilize the platform, and/or virtual machine, and/or machine, and/or execution time system, and/or language architecture, regardless of the machine manufacturer and internal details of the machine. It will also be appreciated in the description provided herein that the platform and/or execution time system can include virtual machine and non-virtual machine software and/or firmware architectures, as well as hardware and direct hardware coding applications and implementations.

Furthermore, the single machine of Figure 14 (a machine that is not connected or coupled by a plurality of parts), or a more general virtual machine or abstract machine environment, such as, but not limited to, an object-oriented virtual machine capable of Immediately guarantee that the specified objects 50X-50Z are different and may be used synchronously without conflict or unwanted interactions by using mutually exclusive (eg "mutex") operators or jobs (including, for example, locking, signaling, monitoring, blocking) Barriers and the like), for example, a programmer using a synchronization example in a computer program written in the JAVA language. Since each object is unique and only localized in this example (this is localization within the machine when execution occurs), the single JAVA virtual machine 72 executing in this single machine in Figure 14 can guarantee an object. (or several objects) may be properly synchronized, as defined by the JAVA virtual machine and language specification present at least on the filing date of this patent specification, when specified by the application (or programmer), and Therefore, the object or objects to be synchronized are only immediately or simultaneously composed of an execution part of the plurality of execution parts and a possible synchronous execution part of the executable application code 50, such as, for example, execution in synchronous execution. Or processing. If the other executable portion of the executable application code 50 and possibly the synchronous execution portion (such as, but not limited to, a thread or process that may be executed synchronously) want to exclusively use the same object, the object is one a subject of a mutually exclusive operation of a first execution portion (such as a first thread or process), such as a second execution portion of a multi-part processing machine (such as a second thread or processing) Attempting to synchronize on a same object that has been synchronized by a first execution portion, and then possible conflicts are resolved by the JAVA virtual machine 72, such that the second and additional execution portions and possibly simultaneous execution portions or Portions of the application 50 must wait until the first execution portion has completed the execution of its synchronization routine or other mutually exclusive operations. It can be seen that in a conventional situation, the second or multiple execution portions of the application or code (ie, a second or multiple threads) may want to use the same in the multi-thread processing machine of FIG. Object.

For a more general combination of virtual machine or abstract machine environments, and for current and future computer and/or computing machines and/or information appliances or processing systems, and which may or may not utilize categories and/or The structure, method, computer program and computer program product of the present invention will still be applicable. Examples of computers and/or computing machines that do not utilize categories and/or objects include, for example, x86 computer architectures manufactured by Intel Corporation and others, SPARC computer architectures manufactured by Sun Microsystems and others, and by IBM Corporation. And the PowerPC computer architecture manufactured by other companies, as well as personal computer products manufactured by Apple Computer and other companies. For these types of computers, computing machines, information appliances, and virtual machines or virtual computing environments that are not implemented using categories or objects, for example, they can be generalized to include basic data types (eg, integer data types). Different, floating point data type, long integer data type, double data type, string data type, symbol data type and Bolling data type), structured data type (such as array and record) Type, or other code or data structure of other procedural languages, or other languages and environments, such as functions, indicators, components, modules, structures, references, and collections.

A similar procedure applies the appropriate amendments to category 50A (ie, with appropriate or necessary changes). In particular, when writing or generating a program using a JAVA language and architecture on a single machine, the computer programmer (or an automated or non-automated computer program generator or means of production if applicable) requires not only A synchronization example to provide for avoiding conflicts or unwanted interactions. Thus, a single JAVA virtual machine can track the unique use of such categories and objects (or other assets) and avoid corresponding problems (such as conflicts, race conditions, unwanted interactions, or other unanticipated due to event-related timing) Abnormal behavior caused by sexual critical interdependence) is needed in an unobtrusive approach. The processing of the only object or category that is uniquely used is called synchronization in the JAVA language. In the JAVA language, synchronization can usually be done or implemented in one of three ways or means. The first method or means is described by using a synchronization method, which is included in the source code of an application written in the JAVA language. The second method or means is a "synchronization descriptor" in a method descriptor that includes an application compiled by one of the JAVA virtual machines. The third method or means for performing synchronization is to monitor entry (such as "monitorenter") and monitor leave (such as "monitorexit") by using the instruction of the JAVA virtual machine, which respectively represent a synchronization example. The beginning and the end, which result in the acquisition or execution of a "lock" (or other mutually exclusive operator or job), and the release or termination of a "lock" (or other mutually exclusive operation or job), which prevents an asset Become the subject of conflicts between multiple and possible simultaneous uses (or race conditions, or unwanted interactions, or other anomalous behaviors that are not expected due to critical timing in the relevant timing of the event). For example, an asset can include a category or an object, as well as any other software/language/execution time/platform/architecture or machine resource. These resources may include, for example, but are not limited to, software programs (such as executable software, modules, sub-programs, sub-modules, application interfaces (APIs), software libraries, dynamic link libraries) and materials (such as Is the data type, data structure, variables, arrays, tables, structures, collections), and memory locations (such as named memory locations, memory ranges, address spaces, scratchpads), and input / Output (I/O) and/or interface, or other machine, computer or information appliance resources or assets.

However, in the configuration illustrated in Figure 8 (also in Figures 31-33), it provides a plurality of individual computers or machines M1, M2, ... Mn, each of which is transmitted through a communication network 53 or Other communication links are interconnected, and each individual computer or machine has a modifier 51 (see Figure 5) and is released, for example, by the Decentralized Execution Time (DRT) 71 (see Figure 8). And loaded with a shared application code 50. The term shared application is understood to mean an application or application code written to be executed on a single machine and loaded on the computer or machine M1, M2...Mn in whole or in part. Or, as needed, on each of the plurality of sub-sets of the plurality of computers or machines M1, M2...Mn. But somewhat differently, there is a shared application, represented by application code 50, and this single copy or possibly multiple identical copies are modified to produce a modified copy or version of the application or code, each A copy or illustration is prepared to be executed on the plurality of machines. After they are corrected, they are considered to be shared if they perform similar jobs and operate consistently and harmonically. It will be appreciated that a plurality of computers, machines, information appliances, or the like, embodying features of the present invention, may be coupled or coupled to other computers, machines, information appliances, or the like that do not implement the features of the present invention, as desired.

In some embodiments, some or all of the plurality of individual computers or machines may be contained within a single enclosure or enclosure (eg, a so-called blade server, by Hewlett-Packard Development, Intel Corporation, IBM Corporation, and others). Manufactured) either on a single printed circuit board or even in a single wafer or wafer set.

Basically, the corrector 51 or DRT 71 can ensure that a portion of the modified application 50 (eg, a thread or process) executed on one or more machines is utilized exclusively (eg, by a synchronization example) Or a similar or equivalent mutual exclusion operator or operation) a specific local asset, such as an object 50X-50Z or category 50A, without any other difference on the machine M2...Mn and possibly performing a partially uniquely immediate Or at the same time utilize an equivalent corresponding asset corresponding to it in its local memory.

It will be appreciated that under the description herein, the modifier 51 and the distributed execution time 71 will have additional implementations. For example, the modifier 51 can implement or be within a component of the distributed execution time 71, such that the DRT 71 can implement the functions and operations of the modifier 51. In addition, the function and operation of the corrector 51 can be implemented in addition to the structure, software, firmware or other means for implementing the DRT 71. In a specific embodiment, the modifier 51 and the DRT 71 are implemented or written in a single paragraph of the computer code, and the functions of the DRT and the modifier are provided. Therefore, the modifier function and structure may be included in the DRT and be regarded as an optional component. In addition to how it is implemented, the modifier function and structure is responsible for modifying the executable code of the application code program, and the distributed execution time function and structure is responsible for implementing communication between the computers or machines. The communication functions in a particular embodiment are implemented by an intermediate protocol layer within the computer code of the DRT on each machine. For example, the DRT can implement a communication stack in the JAVA language and use the Transmission Control Protocol/Internet Protocol (TCP/IP) to provide communication or conversation between the machines. In fact, how these functions or operations are implemented or divided between structural and/or procedural elements, or between the computer code or data structure of the present invention, is less important than the ones they provide.

Accordingly, it will be appreciated that the invention may include any means of implementing thread security, whether through the use of lock (lock/unlock), synchronization, monitor, SEMPHAFORES, mutex, or Other mechanisms.

It will be understood that synchronization represents or indicates "unique use" or "mutual exclusion" of an asset or resource. Conventional structures and methods for implementing a single computer or machine have developed methods for synchronizing on such a single computer or machine configuration. However, these conventional structures and methods do not provide a solution for synchronizing between multiple computers, machines, or information appliances.

In particular, when a particular machine (such as, for example, machine M3) uniquely uses an object or category (or any other asset or resource), another machine (such as, for example, machine M5) may also be indicated by the code. Execution to uniquely use a similarly similar item or category corresponding to the equivalent item or category on machine M3 during a simultaneous or overlapping period of time. Therefore, if the same corresponding equivalent object or category on each machine M3 and M5 is to be uniquely used by both machines, the behavior of the object and the application as a whole is not defined, that is, when explicitly When a computer program (programmer) specifies a proper unique use of an object (or category), it may cause conflicts, unwanted interactions on machines M5 and M3 due to unintended dependencies of the relative timing of events. , anomalous behavior, or a permanent inconsistency between similar objects. Therefore, it is impossible to achieve a synchronization example (or other mutual exclusion operation) between the plurality of machines required for the synchronization and coordination of the same application code on each of the plurality of machine M1, M2...Mn. To achieve or provide consistency, coordination, and reconciliation operations.

In order to ensure consistency synchronization between the machines M1, M2...Mn, the application code 50 is analyzed or scrutinized by looking for the entire executable application code 50 to detect the program steps in the application code 50 ( For example, a particular instruction or instruction type) may be defined or constructed, or otherwise represent a synchronization instance (or other mutually exclusive operation). In the JAVA language, these program steps may include, for example, or have open monitoring input (such as "monitorenter") instructions, and one or more closed monitoring and leaving (such as "monitorexit") instructions. In a specific embodiment, a synchronization example can be initiated by executing a "monitorenter" instruction and ending with a paired execution of a "monitorexit" instruction.

The analysis or scrutiny of the application code 50 may occur prior to loading the application code 50, or during loading of the application code 50, or even after the application code 50 loads the program. It can be similar to an installation, program conversion, translation, or compiler, where the application code can be implemented with additional instructions, and/or can be modified by meaning retention program manipulation, ie, or alternatively by an input code language. Translating into a different code language (for example, translation from a source code language or an intermediate code language to an object code language or a machine code language), and knowing that the term compilation usually or customally contains changes in the code or language, such as From source code or object code, or from one language to another. However, in this example the term "compilation" (and its grammatical equivalents) is not so limited and may include or contain amendments within the same code or language. For example, the compilation and its equivalents can be understood to include both normal compilation (eg, by way of illustration and not limitation, from source code to object code), and compiled from source code to source code, and compiled from object code to object. The code, and any combination of any of them. It may also include a so-called "intermediary language" in the form of "virtual object code".

By way of illustration and not limitation, in one embodiment, analysis or scrutiny of the application code 50 may occur during loading of the application code, such as by the operating system from the hard disk or other storage device or source. The application code is read, copied to memory, and ready to begin execution of the application code. In another embodiment, in a JAVA virtual machine, the analysis or scrutiny can occur during a class loader of the java.lang.ClassLoader loadClass method (eg, java.lang.ClassLoader.loadClass()).

In addition, the analysis or scrutiny of the application code 50 can occur even after the application code loading program, for example, after the operating system has loaded the application code into the memory, or alternatively even in the application code. After the relevant part has been started or carried out, for example, after the JAVA virtual machine has loaded the application code into the virtual machine, it passes the "java.lang.ClassLoader.loadClass()" method, and Execute selectively.

Please refer to the attached Appendix D, where: Appendix D1 is a typical code segment of a synchronization example before correction (such as an example uncorrected synchronization example), and Appendix D2 is the same synchronization example after correction. Equation (for example, an example of a modified synchronization). These code segments are merely exemplary and a software code means can be identified for performing the corrections in an exemplary language. It will be appreciated that other software/firmware or computer code can be used to accomplish the same or similar functions or operations without departing from the invention.

Appendices D1 and D2 (also partially reproduced in Tables XX and XXI below) are exemplary code list columns that provide the conventional or uncorrected computer program software code for one of the application 50 initialization examples (eg A post-correction excerpt of the same initialization equations, which can be used in a single machine or computer environment, for example, can be used in the specific embodiment of the invention having multiple machines. The corrected code added to the synchronization method is highlighted in bold text. Other embodiments of the invention may provide code, or narration, or instructions to be added, modified, removed, moved or reorganized, or otherwise altered.

It should be noted that the compiled code in the appendix and the part in the form repeated in the table are in the form of the file "example.java", which is included in Appendix D3. The decoded compiled code listed in this appendix and table is compiled from the original code in the file "EXAMPLE.JAVA". In the procedures of Appendix D1 and Table XX, the program name "Method void run()" of step 001 is the name of the decoded output of the display of the execution method of "example.java" compiled with the application code. The name "Method void run()" is optional, and this example is chosen to represent a typical JAVA method that includes a synchronized job. The method as a whole is responsible for adding a memory location ("counter") by using a synchronized statement in a thread-safe manner, and sequentially illustrates the steps to achieve this.

First (step 002), the Java virtual machine instruction "getstatic #2<Field java.lang.Object LOCK>" causes the Java virtual machine to retrieve the second index of the classfile structure stored in the application containing the example run() method. The object referenced by the static field indicated by the CONSTANT_Fieldref_info constant-pool item, and causes a reference to the object (hereinafter referred to as LOCK) to be placed (pushed) in the field in the current execution thread The current method frame is stacked on the stack.

Next (step 003), the Java virtual machine instruction "dup" causes the Java virtual machine to copy the top item of the stack and push the copied item to the uppermost position of the stack of the current method frame, and causes The reference to the LOCK object at the top of the stack is copied and pushed onto the stack.

Next (step 004), the Java virtual machine instruction "astore_1" causes the Java virtual machine to remove the topmost item of the stack of the current method frame and store the item to the local variable array of index 1 of the current method frame. And causing the topmost LOCK object reference of the stack to be stored in the local variable index 1.

Then (step 005), the Java virtual machine instruction "monitorenter" causes the Java virtual machine to push the top object away from the stack of the current method frame, and obtain one of the items on the pushed object to exclude the lock and cause a lock Obtained on the LOCK object.

The Java virtual machine instruction "getstatic #3<Field int counter>" (step 006) causes the Java virtual machine to retrieve the third index of the classfile structure of the application containing the example run() method from the CONSTANT_Fieldref_info constant-pool entry. The integer value of the static field is indicated, and the integer value of the field is placed (pushed) on the stack of the current method frame of the currently executing thread.

The Java virtual machine instruction "iconst_1" (step 007) causes the Java virtual machine to load an integer value "1" onto the stack of the current method frame and cause the integer value 1 to be loaded into the current method frame. At the top of the stack.

The Java virtual machine instruction "iadd" (step 008) causes the Java virtual machine to perform an integer addition of the top two integer values of the stack of the current method frame, and causes the resulting integer value of the addition operation to be placed The top of the stack of the current method frame.

The Java virtual machine instruction "putstatic #3<Field int counter>" (step 009) causes the Java virtual machine to push the topmost value out of the stack of the current method frame and store the value in the sample run() The third index of the application's classfile structure is in the static field indicated by the CONSTANT_Fieldref_info constant-pool item, and the uppermost integer value of the stack of the current method frame is stored in the name "counter". In the integer field.

The Java virtual machine instruction "aload_1" (step 010) causes the Java virtual machine to load the project into the local variable array at index 1 of the current method frame and store the item in the stack of the current method frame. At the top, and causing object references in the local variable array stored at index 1 to be pushed onto the stack.

The Java virtual machine instruction "monitorexit" (step 011) causes the Java virtual machine to push the stack of the topmost object away from the current method frame and release the excluded LOCK on the pushed object and cause a lock on the LOCK The object is released.

Finally, the Java virtual machine instruction "return" (step 012) causes the Java virtual machine to stop executing the run() method by returning control to the previous method frame and causing the execution of the run() method to terminate. .

Due to these steps of working on a single machine configured in the first and second figures, the synchronized description of the increase operation including the "counter" memory position ensures that there will be no two in the run() method. One or more simultaneous execution instances will conflict, or otherwise cause unwanted interactions, such as a race condition due to an unexpected critical dependency of the relative timing of the increased event performed at the location of the "counter" memory or Other abnormal behavior. If these steps are to be performed on a plurality of machines in the configurations of Figures 5 and 8, and have the memory update and transfer copying means of Figures 9, 10, 11, 12 and 13, and execute the run synchronously ( Two or more examples or events of the method, each of which is performed on a different machine in the plurality of machines M1, M2...Mn, and each of the run() methods simultaneously performs an exemplary mutual exclusion operation Execution is performed on each of the counterparts of the machines without the need for coordination between those machines.

Given the consistency of synchronized operations across multiple machines, this prior art configuration would not be able to perform this coordinated synchronization of the machines across the complex machine because each machine is only executing locally Synchronization, without any attempt to coordinate their local synchronization jobs, utilizes any other similar synchronization jobs on any one or more other machines. So this configuration will be a conflict between these machines M1, M2, ..., Mn or other unwanted interactions (such as race conditions or due to the relative timing of events added to the "counter" on each machine) Other abnormal behaviors of unexpected critical dependencies). It is therefore an object of the present invention to overcome this limitation of this prior art configuration.

In the sample code in Table XXI (Appendix D2), the code has been corrected, so it solves the problem of the coordinated operation of the consistency of the complex machines M1, M2, ..., Mn, which is not The code example from Table XX (Appendix D1) is resolved. In the modified run() method code, a "dup" instruction is inserted between the "4 astore_1" and "6 monitorenter" instructions. This causes the Java virtual machine to copy the topmost item of the stack and push the copied item to the uppermost position of the stack of the current method frame and cause the LOCK object to be located at the top of the stack. The reference is copied and pushed onto the stack.

Furthermore, the Java virtual machine instruction "invokestatic #23<Method void acquireLock(java.lang.Object)>" is inserted after the "6 monitorenter" and before the "10 getstatic #3<Field int counter>" statement. Therefore, the Java virtual machine launches the stack of the current method frame leaving the current method frame, and raises the "acquireLock" method, and transmits the launched item to the new method frame as its first argument. This change is particularly noticeable because it corrects the run() method to execute the "acquireLock" method and associated operations, corresponding to its previous "monitorenter" instruction.

Appendix D1 is an excerpt from the revision of the decoding and compilation form of the synchronization operation of example.java of Appendix D3, which includes a start "monitorenter" instruction and an end "monitorexit" instruction. Appendix D2 is the form after the amendment of Appendix D1, as amended by LockLoader.java in Appendix D6 of the steps in Figure 26. These corrections are highlighted in bold.

The method void acquireLock (java.lang.Object), part of the LockClient code of Appendix D4, and part of the Decentralized Execution Time System (DRT) 71, which performs communication operations between the machines M1...Mn, Coordinate the execution of the previous "monitorenter" synchronization job between the machines M1...Mn. The applyLock method of this example communicates with the LockServer code of Appendix D5 executed on machine X of Figure 15, by transmitting an 'acquire lock request' to the machine X corresponding to the object being locked (ie corresponding to the "monitorenter" "The object of the instruction", which is the 'LOCK' object in the text of Table XXI and Appendix D2. Please refer to Figure 29, machine X receives the 'acquire lock request' corresponding to the LOCK object, and consults a locked The table determines the lock status corresponding to the plurality of similarly equivalent items on each machine, which in the example of Appendix D2 is the plurality of similar equivalent LOCK objects.

If all of the plurality of similar equivalents on each machine M1...Mn are not currently locked by any other machine M1...Mn, then Machine X will record the object as now locked and notify the lock. The machine that was successfully obtained. In addition, if a similar equivalent is currently locked by the other of the machines M1...Mn, the machine X will join the requesting machine until it waits for the machine to lock the plurality of equivalent objects until Machine X determines that this requires the machine to acquire the lock. Corresponding to a lock obtained by the success of a requesting machine, a reply is generated, and the machine transmitted to the successful request informs the machine that the lock has been successfully obtained. After receiving such a message from machine X and confirming the successful acquisition of a required lock, the acquireLock method and the job terminate execution, and return control to the previous method frame, which is the text of Appendix D2, that is, The method frame in the execution of the run() method. Until the requesting machine receives a reply from machine X and confirms that the lock was successfully obtained, the operations of the acquireLock method and the run() method are suspended until a confirmation reply is received. After the job is returned here, the execution of the run() method is restarted. An exemplary source code for a particular embodiment of the acquireLock method is provided in Appendix D4. Additional details on the DRT 71 function are also provided in Appendix D4.

Later, the two narratives "dup" and "invokestatic #24<Method void releaseLock(java.lang.Object)>" are inserted into the code stream, after the "18 aload_1" statement and the "23 monitorexit" "Before the narrative. These two narratives cause the Java virtual machine to copy the project on the stack, and then raise the releaseLock method to use the topmost item of the stack as an argument to the method call, and cause the run() method to be modified to execute The "releaseLock" method and related operations correspond to the following "monitorexit" instructions before the program leaves and returns.

The method void releaseLock (java.lang.Object), part of the LockClient code of Appendix D4, and part of the Decentralized Execution Time System (DRT) 71, which performs communication operations between the machines M1...Mn, Coordinate the execution of the "monitorexit" synchronization job between these machines M1...Mn. The releaseLock method of this example communicates with the LockServer code of Appendix D5 executed on machine X of Figure 15 by transmitting a 'release lock request' to machine X corresponding to the unlocked object (ie corresponding to the "monitorexit" "The object of the instruction", which is the 'LOCK' object in the text of Table XXI and Appendix D2. Corresponding to Figure 30, Machine X receives the "release lock request" corresponding to the LOCK object and updates the locks. a table to indicate that the lock status corresponding to the similar equivalent 'LOCK' object becomes the current "unlocked". In addition, if another machine is waiting to acquire the lock, the machine X can select one of the waiting machines to become the new owner of the lock, by updating the lock table to specify that the selected one of the selected machines becomes The new lock owner and notifies the one of the waiting machines that one of the successful machines has successfully locked the lock by a confirmation reply. Then wait for a successful part of the machine to resume execution of its synchronization example. After notifying the machine X lock release, the releaseLock method terminates execution and returns control to the previous method frame, which in this example is the method frame of the run() method. After the job is returned here, the execution of the run() method is restarted.

It will be appreciated that the modified code allows for the coordination of the synchronization instance or other mutually exclusive operations between the machines M1...Mn in a distributed computing environment having a plurality of computers or computing machines, so Problems with uncorrected code or program operations on the plurality of machines M1...Mn (eg, such as conflicts, unwanted interactions, race conditions, or abnormalities due to unanticipated critical dependencies of events over time) Behavior) does not occur when the modified code or program is applied.

In the unmodified code example of Appendix D1, the application code includes instructions or jobs for adding a memory location to a local memory (for a counter) in a overlay synchronization instance. The purpose of this synchronization example is to ensure that the counter memory increases the thread security of the job in multiple threads and multiprocessing applications and computer systems. The term thread security or thread security represents a code that is re-entered or protected by a mutually exclusive and multiple simultaneous execution. The application of multiple threads in the context of the present invention may, for example, include the application of two or more threads that are executed concurrently on each different machine. Therefore, there is no coordinated coordination of management in an environment that contains or has a plurality of machines, each of which executes a portion of the same application simultaneously, and has a memory of the 9, 10, 11, 12, and 13 graphs. Update and transfer replication means that each computer or computing machine will perform synchronization independently, thereby potentially increasing the shared counters simultaneously, causing possible conflicts or unwanted interactions, such as between these machines M1...Mn Competition status and irreconcilable memory. It will be appreciated that while this particular embodiment uses a shared counter to illustrate, the use or provision of such shared counter or memory locations is optional and is not required for the synchronized aspects of the present invention. Preferably, the behavior of the synchronization example is guaranteed by the stylized language, execution time system or machine architecture (or any combination thereof), that is, stopping the two parts of the application (eg, two executions) To perform the same synchronization example or the same mutex operation or operator synchronously. Clearly consistent, reconciled, and coordinated synchronization behavior is the program or user of the application code 50 expected to occur.

Therefore, with the benefit of the DRT 71, the application code 50 is modified to be loaded into the machine by changing the synchronization example. It will be understood from the description provided herein that such corrections made to each machine can generally be similar to this extent, as they must preferably be consistent with the coordinated synchronization of operations between all machines. The end result; however, given the broad applicability of the inventive synchronization method and associated procedures, the nature of the corrections can generally be changed without altering the effects produced. For example, in a simple variation, one or more additional instructions or narratives can be inserted, such as, for example, a "nop" type of instruction into the application, which will represent the corrections made to Technically different, but the modified code still conforms to the present invention. For example, a particular embodiment of the invention can be implemented by various means of program conversion, translation, compilation, testing, or by other means described herein or as known in the art. The changes (in bold) are the start or initial instructions and the end instructions executed by the synchronization example, and respectively correspond to the entry (start) and departure of the synchronization example (At last). These added instructions (or modified instruction streams) are used to coordinate instances or events of multiple executions of the modified execution method performed on each or a subset of the complex machines M1...Mn. The execution of the synchronization instance is initiated by causing an acquireLock method corresponding to the start of the synchronization instance and by initiating a releaseLock method corresponding to the end of the synchronization example. A coherently coordinated operation (or other mutually exclusive operation or operator) of synchronization instances required to operate simultaneously across the modified application code executed on the complex machine M1, M2, ... Mn. It is also preferred to provide an operation that spans one of the machines in a coordinated manner.

The DRT 71 is locked (eg, the "acquireLock()") method takes an argument ("(java.lang.Ojbect)"), which represents a reference (or some other unique identifier) to that particular local object, where This generic lock is required (see Appendix D2 and Table XXI) to obtain a common lock across a plurality of similar equivalents on other machines corresponding to the specified local object. For example, the unique identifier may be the name of the object, a reference to the object in question, or a unique number representing the plurality of similar objects across all nodes. By using a universally unique identifier across all connected machines to represent a plurality of similar objects on the complex machine, the DRT can simultaneously support synchronization of multiple objects without confusion because of the plurality of The object has been synchronized, and it does not have an object (or category) identification item that is not unique, by using the unique identification of each item to look up the correct record in the shared synchronization table.

Another benefit of using a generic identifier here is that it can be used as a 'meta-name' for all similar native objects on each machine. For example, in addition to having to trace each unique local name for each similarly equivalent local object on each machine, it can also define a common name (such as "globalname7787"), where each local machine is sequentially mapped to a local The object (such as "globalname7787" corresponds to the object "localobject456" on the machine M1, and "globalname7787" corresponds to the object "localobject885" on the machine M2, and "globalname7787" corresponds to the object "localobject111" on the machine M3, and so on. It is then easier to simply call "lock on globalname7787", then translate it to machine 1 (M1) to indicate "lock on localobject456" and translate it to machine 2 (M2) to indicate "lock on localobject885" "and many more.

The shared synchronization form that may be used as needed may be a form, and other storage means, or any other data structure, may store an object (and/or category or other asset) of each object (and/or category or other asset). Item and the synchronization status (or locked or unlocked status). The form or other means of storage is used to associate an object (and/or category or other asset, or a plurality of similar items or categories or assets) to a locked state and an unlocked state that is locked or unlocked or some other entity Or the state of the logical representation. For example: the form (or any other data structure that is intended to be used) preferably includes a named object identification item and an object representing whether the name is (ie, "globalname7787") is locked or unlocked. recording. In a specific embodiment, the form or other storage means stores a flag or a memory bit, wherein when the flag or memory bit stores a "0", the object is unlocked, and when the flag or When the memory bit stores a "1", the object is locked. Clearly, multiple bit or byte storage can be used, and different logical concepts or indicators can be used without departing from the invention.

The DRT 71 can use any of several methods to determine the synchronization state of the object. It is contemplated that the present invention, for example, can include any means of implementing thread security, whether or not it uses lock (lock/unlock), synchronization, monitor, SEMPHAFORES, mutex lock, or other mechanism. These representatives stop or limit the execution of a single application's execution portion to ensure consistency based on synchronization, locking, or similar rules. Preferably, it is sequentially required that each machine is currently synchronized if its local similar equivalent (or category or other asset or resource) corresponding to the object being sought to be locked, and if any machine When the reply is true, the execution of the synchronization instance can be suspended, and wait until the similarly equivalent object currently synchronized on other machines is unsynchronized, otherwise the object is synchronized locally and the synchronization is restarted. Execution of the example. Each machine can implement synchronization (or mutual exclusion operations or operators) in its own way, and this can be different on different machines. Thus, while some example implementation details are provided, how the final synchronization (or mutex operation) is implemented, or how the synchronization or mutex state (or locked/unlocked state) is accurately recorded in memory or other storage Among the means, it is not the key to the invention. By not synchronizing, we usually represent unlocked or unmuted, and by synchronization, we usually represent being locked and subject to a mutually exclusive operation.

In addition, the DRT 71 on each local machine can consult a shared record sheet (possibly on a separate machine (eg on machine X other than machines M1, M2, ..., Mn), or can be consulted A toned and shared record form on each of the local machines, or a shared library in a memory or other storage to determine if the object has been marked or identified as being synchronized by any machine. (or "lock"), if so, wait until the state of the object is changed to unlocked, then take the lock on the machine, otherwise the object is locked by marking it in the shared lock table (view) This machine needs to) get the lock.

In the case where the shared record table is viewed, this can be viewed as a change in a shared repository or data structure, where each machine has a local copy of the shared form (this is a copy of the shared form) that is updated To maintain the harmony of the plurality of machine parts M1, ..., Mn.

In a specific embodiment, the shared record table represents a shared form accessible by all machines M1, . . . , Mn, which may, for example, be defined or stored in a shared access database such that any machine M1,..., Mn can refer to or read the locked or unlocked state of an object in this shared database table. Another configuration is to implement a shared record table as a table in an additional machine's memory (which we call "machine X"), which stores each object identification name and its lock status as the center. storage area, which may be all other machines M1, ..., M _N Now the lock state or a similar level decision object.

In any of these various alternative implementations, it is relatively unimportant and available to identify or identify one or more similar equivalents in the method as being synchronized (or locked) or unsynchronized (or unlocked). A plurality of stored memory bits or bytes or flags are used to identify one of the two possible logic states, which are well known in the art. It will be appreciated that in this particular embodiment, the synchronization is very similar to locking, and unlocking is very similar to unlocking. These same considerations can be applied to categories and to other assets or resources.

Consider that the DRT 71 is responsible for determining the locked state of an object (or category, or other asset, corresponding to a plurality of similar equivalent objects or categories or assets) that is allowed before the synchronization instance corresponding to the acquisition is allowed to proceed. locking. In the exemplary embodiment described herein, the DRT refers to the shared synchronization record table, which in a specific embodiment exists on a special "machine X", so the DRT needs to pass through the network. Or other communication link or path communicates with the machine X to make an inquiry and determine the locked (or unlocked) state of the object (or category, or other asset, corresponding to a plurality of similar equivalent objects or categories or assets).

If the DRT on the local machine attempting to perform a synchronization or other mutual exclusion operation determines that no other machine currently has this object (ie no other machine has synchronized the object) or any of a number of similar equivalents A lock of the person is to obtain a lock corresponding to the object corresponding to the plurality of equivalent objects on all other machines, for example, by correcting the corresponding entry in the shared form that seeks the locked state of the object to be locked. Or, in addition, sequentially acquire locks on all other similar equivalents on all other machines except the current machine. Please note that this program is to lock the same number of equivalent items (or categories or assets) on all other machines M1,..., Mn, so that it is possible to prevent any similar or equivalent use of two or more machines simultaneously or simultaneously. Objects and can use any available method to accomplish this coordinated lock. For example, whether or not machine M1 instructs M2 to lock its similar peer local object, instructs M3 to lock it like an equivalent local object, then instructs M4, etc.; or if M1 instructs M2 to lock it like an equivalent local object, then M2 instructs M3 to lock it Similar to an equivalent local object, then M3 instructs M4 to lock its equivalent to an equivalent local object, and so on, it is thought of locking these similar objects on all other machines, so that two or more machines can be prevented from being simultaneously or simultaneously Use any similar equivalent. The synchronization example or code block can only be executed when the machine has successfully confirmed that no other machine has currently locked a similar object and that the machine has correspondingly locked its local equivalent.

On the other hand, if the DRT 71 in the machine (e.g., machine M1) that is about to execute a synchronization example determines that another machine (e.g., machine M4) has synchronized a similar object, the machine M1 is to delay the Synchronization of the continuous execution of the example (or code block) until the DRT on the machine M1 can confirm that no other machines (eg, machines M2, M3, M4, or M5, ..., Mn) are currently in the process A corresponding similar local object performs a synchronization example, and the machine M1 has correspondingly synchronized its similar equivalents locally. Note that local synchronization represents the prior art synchronization of synchronization on a single machine, whereas general or coordinated synchronization represents spanning similar equivalent local objects and/or over one of the complex machines M1...Mn. Synchronization of coordination between them. In this example, the synchronization example (or code block) is not to be executed until the machine M1 can guarantee that no other machines M2, M3, M4, ..., Mn are performing localizations to be sought to lock. Synchronization of a similar example of one of the equivalents, as it would potentially destroy objects across the participating machines M1, M2, M3, ..., Mn due to conflicts or other unwanted interactions, such as Contest status, and similar issues arising from simultaneous execution of synchronized instances. Therefore, when the DRT determines that the object or a similar object on another machine is currently "locked", for example by machine M4 (relative to all other machines), the DRT on machine M1 suspends the synchronization example. Execution, by suspending the execution of the lock (eg, acquireLock()) until a corresponding release lock (eg, releaseLock()) job is executed by the current owner of the lock (eg, machine M4).

Therefore, when performing a release lock (such as a releaseLock()) job, the machine M4 that currently "owns" or keeps a lock (ie, is performing a synchronization routine) indicates that the synchronization instance is closed, for example by marking This object becomes "unlocked" in the shared lock status table, or otherwise releases the locks acquired on all other machines. At this point, waiting for a different machine to start executing a paused synchronization statement can claim ownership of the now released lock by restarting the execution of its delayed (ie, delayed) "acquireLock()" job. For example, by indicating itself as a lock on the equivalent object in the shared synchronization state table, or otherwise obtaining a local lock similar to the equivalent on each other machine. It is to be understood that the restart of the acquisition lock (such as "acquireLock") includes the selective restart of the acquisition lock (such as "acquireLock"), the execution is suspended, and the optional configuration, The execution of the lock (eg "acquireLock") is repeated to re-request the lock. Again, these same considerations apply to categories, and more generally to any asset or resource.

Therefore, in accordance with at least one embodiment and the benefit of the operation of the DRT 71, the application code 50 is modified to change the synchronization example (including at least one start "acquire lock" type instruction (eg, a JAVA). The monitorenter "instruction" and an "release lock" type instruction (such as a JAVA "monitorexit" instruction) are loaded into the machine. The "Acquire lock" type instruction performs a mutually exclusive operation or execution, which is usually Corresponds to a particular asset, such as a particular memory location or machine resource, and causes the asset corresponding to the mutually exclusive operation to be locked with respect to some or all of the modes, executions, or jobs used simultaneously or synchronously. "Release lock" type An instruction terminates or interrupts a job or execution that performs a mutually exclusive operation, which typically corresponds to a particular asset, such as a particular memory location or machine resource, and causes the asset corresponding to the mutually exclusive operation to be relative to some or all of the simultaneous or Unlocked using the mode, execution, or job used synchronously. The changes made (in bold) are the instructions for the corrections performed by the synchronization example. For example, these added The instruction checks if the lock has been taken by another machine. If the lock has not been taken by another machine, the DRT of the machine notifies all other machines that the machine has obtained the specified lock, thereby stopping other machine executions corresponding to A synchronized example of this lock.

The DRT 71 can determine and record the locked state of a similar synchronized object, or the corresponding memory location or machine or software resource on other plurality of machines, which can be used in a variety of ways, such as by way of example but not limitation: 1. Corresponding to In a synchronized instance of the entry in machine M1, the DRT of machine M1 individually consults or passes each machine to determine if this universal lock has been obtained by any other machine M2,..., Mn different from itself. . If the universal lock corresponding to this asset or object is or has been taken by another of the machines M2,..., Mn, the DRT of machine M1 suspends execution of the synchronized instance on machine M1 until all Other machines no longer have a universal lock on this asset or object (meaning that no other machine no longer has a universal lock corresponding to one of the assets or objects), at which point machine M1 can successfully acquire the universal lock, making all The other machines M2,..., Mn must now wait for the machine M1 to release the universal lock before a different machine can take it in sequence. Otherwise, when it determines that the universal lock corresponding to the asset or object has not been taken by another machine M2,..., Mn, the DRT continues to perform the execution of the synchronization example and causes all other machines M2, ..., Mn must now wait for machine M1 to release the universal lock before a different machine can acquire it in sequence.

In addition, 2. corresponding to a synchronization example of the entry, the DRT refers to a shared record form (such as a shared database, or a copy of a shared form on each participating machine), if any The machine currently "owns" this universal lock. If so, the DRT suspends the execution of the synchronization instance on this machine until no machine has a universal lock on a similar object. Otherwise the DRT records that the machine becomes the owner of this universal lock in the shared table (or table, if there are multiple record tables, such as on multiple machines), and then proceeds to the synchronization instance.

Similarly, when a general lock is released, that is, when the execution of a synchronization instance is about to end, the DRT can "not record", change the status indicator, and/or reset the status in many other ways. The general lock state of the machine, for example by way of illustration and not limitation: 1. Corresponding to the departure of a synchronized instance, the DRT individually informs each of the other appliances that they no longer possess the universal lock.

In addition, 2. corresponding to the departure of a synchronization example, the DRT updates the record to the universally locked asset or object (such as, for example, a plurality of similar objects or assets) in the shared record table, such that the machine It is no longer recorded as having this universal lock.

In addition, the DRT can provide a universal lock queue to arrange for a machine to obtain a universal lock, for example by way of illustration but not limitation: 1. Corresponding to a log-in synchronization example of the machine M1, such as a machine The DRT of M1, which notifies the currently-owned machine M1 of the universal lock (such as machine M4), will or need to obtain the corresponding universal lock when released by the currently owned machine, thereby performing a job. The designated machine M4, if there is no other waiting machine, stores the records of the requested machine (such as the machine M1) that are of interest or demand in a table or list, so that the machine M4 can know that the corresponding corresponding release is to be released. Locking, wherein the machine M1 recorded in the table or table column is waiting for the same universal lock to be obtained, after leaving the synchronization instance corresponding to the universal lock held by the machine M4, Waiting for the waiting machine (ie machine M1) specified in the machine record to take the universal lock, and thus machine M1 can proceed to take the universal lock and continue to execute its own synchronization routine.

2. Corresponding to the entry by the synchronization instance of one of the machines 1, the DRT notifies the current owner of the universal lock (such as machine M4) that a particular machine (such as machine M1) will be in the machine (ie machine) M4) Release the lock to obtain. The machine M4 finds that one or more other machines (such as machines M2 and M7) are waiting after it has queried the record of the waiting machine for the locked object, that is, joining the machine M1 to the machine M2 that wants to acquire the locked object. The end of the M7 list, or otherwise transfer the request from M1 to the first waiting machine (ie machine M2), or any other waiting machine (ie machine M7), and then record the machine M1 in the waiting machine In their form or record.

In the above examples, for example, the records may remain on the machine M4 and store a queue or other ordered or indexed machine list that is waiting to be acquired after the machine M4 releases the lock it holds. locking. This list or queue can then be used or referenced by M4, so M4 can transfer the lock to other machines in accordance with the order of the requirements or any other preferred scheme. Additionally, the list of columns can be unordered, and machine M4 can transfer the generic lock to any machine in the list or record.

3. Corresponding to a synchronization example entry, the DRT record itself in a shared record form (eg, stored in a shared database accessible by all machines, or substantially similar) Separate forms).

In addition or in addition, the DRT 71 can notify other machines that are queued to obtain this universal lock corresponding to the departure of a synchronization instance of the machine, which can be used in the following ways, for example: 1. Corresponding to Upon exit of a synchronization instance, the DRT notifies one of the waiting machines (e.g., the first machine in the queue of the waiting machine) that the universal lock is released.

2. Corresponding to the departure of a synchronization instance, the DRT notifies a part of the waiting machine (eg, the first machine in the queue of the waiting machine) that the universal lock is released and additionally provides the entire machine A copy of the queue (for example, the second machine and subsequent machines waiting for this universal lock). In this way, the second machine inherits the waiting machine list by the first machine, and thereby ensures the continuity of the queue of the waiting machine, and is obtained by each machine below the order in the table column. The same universal lock is subsequently released.

During the above-mentioned scrutiny, the "monitorenter" and "monitorexit" instructions (or methods) are initially searched, and when found, a correction code is inserted to evoke a modified synchronization example. This modified example additionally acquires and releases the universal lock. There are several different modes in which this correction can be made and loaded.

As can be seen from Fig. 15, the modification of the general configuration of Fig. 8 provides that the machines M1, M2...Mn are as before, and the same application is executed simultaneously or synchronously on all machines M1...Mn. Code 50 (or many codes). However, the previous configuration was modified by the provision of a server machine X, which was convenient to be able to supply housekeeping functions, such as, in particular, synchronization of structures, assets and resources. This server machine X can be a low value commercial computer, such as a PC, because of its low computational load. As indicated by the dashed lines in Figure 15, the two server machines X and X+1 can be provided for redundancy purposes to increase the overall reliability of the system. When both server machines X and X+1 are provided, they are preferably, but can be operated as, redundant machines in a non-failed environment.

It does not need to provide a server machine X because its computational load can be spread over the machines M1, M2...Mn. In addition, a database operated by a machine (in a master/controlled class job) can be used for housekeeping functions.

Figure 16 shows a preferred general procedure to follow. After the load 161 has been performed, the instructions to be executed are considered to be in the sequence, and all synchronization instances are detected as shown in step 162. In the JAVA language, these are "monitorenter" and "monitorexit" instructions, and the methods are marked as synchronized in the method descriptor. Other languages use different terms.

When a synchronization instance is detected 162, it is modified in step 163 to synchronize, coordinate, and reconcile the synchronization operations (or other mutual exclusion operations) across the complex machines M1...Mn. Basically, by inserting other instructions into the synchronization (or other mutually exclusive) example, for example, similar synchronization or other mutuals on the other one or more of the complex machines M1...Mn The operation of the synchronization example between the operations is coordinated, so no two or more machines perform a similar equal synchronization or other mutual exclusion operation immediately or overlappingly. In addition, the correction instructions can be inserted before the example, such as before an instruction or job related to a synchronization example. Once the modification step 163 has completed the loading procedure, the application code loaded with the corrections continues to replace the uncorrected application code, as indicated in step 164. The corrections are preferably in the form of "lock on all other machines" and a "release lock on all other machines" correction, as indicated in step 163.

Figure 27 shows a specific form of a correction. First, the structures, assets or assets (referred to as categories or objects in JAVA, such as 50A, 50X-50Y) or more generally "locked" become synchronized, which have been configured with a name or label (eg one A generic name or label) that can be used to identify similar equivalent local objects or assets or resources or locks on each machine M1...Mn, as indicated by step 172. This preferably occurs when the categories or objects are originally initialized. This is most conveniently accomplished by a form maintained by the server machine X. This form also includes the synchronization status of the category or object or lock. It will be appreciated that this form or other data structure may only store the synchronized state, or it may store other states or information. In the preferred embodiment, the table also includes a queue configuration that stores the identification of the machine that has requested the use of the asset or lock.

As shown in step 173 of Figure 27, an "acquire lock" request is then transmitted to machine X, after which the transfer machine waits for an acknowledgment lock acquisition, as shown in step 174. Thus, if the generic name has been locked (ie, a corresponding local asset is uniquely used by another machine other than the machine that is proposing the lock), then this represents the corresponding object or category or asset. Or the proposed synchronization instance of the lock must be suspended until the corresponding object or category or asset or lock is unlocked by the current owner.

In addition, if the generic name is not locked, this means that no other machine uniquely uses a similar category, object, asset, or lock, and confirms that the lock was received immediately. After receiving the acknowledgment lock acquisition, execution of the synchronization modality is allowed to continue, as shown in step 175.

Figure 28 shows the program followed by the execution of the machine by the application that wants to give up a lock. This initial step is indicated in step 181. The operation of the proposed machine is temporarily interrupted by steps 183, 184 until the reply is received from machine X, corresponding to step 184, and executed, and then restarted, as indicated in step 185. If desired, and as shown in step 182, the release of a locked machine is required to find the "common name" for the lock, before the machine X makes a request. In this way, multiple locks can be acquired and released on multiple machines without interfering with each other.

Figure 29 shows the activity performed by machine X in response to an "acquire lock" query (Figure 27). After receiving an "acquire lock" request in step 191, the locked state is determined in steps 192 and 193, and if not, the named resource is not free, or otherwise "locked", the query machine is identified Step 194 is added to (or formed) a queue waiting to be obtained. In addition, if the answer is yes, the named resource is free and "unlocked" and the corresponding reply is transmitted in step 197. The waiting query machine can then execute the synchronization example by performing step 175 of Figure 27 accordingly. In addition to the response to the yes, the shared form is updated in step 196, so the state of the universally named asset is changed to "locked".

Figure 30 shows the activities performed by Machine X in response to the "release lock" requirement of Figure 28. After receiving a "release lock" request in step 201, machine X, as needed and preferably confirms that the machine that is required to release the universal lock is indeed the current owner of the lock, as indicated in step 202. Then, the queue status is determined in step 203, and if none is waiting to acquire the lock, machine X indicates that the lock is "not owned" (or "unlocked") in the shared table, as in step 207. And return a confirmation of the release to the requesting machine as needed, as shown in step 208. This causes the machine in the request to perform step 185 of Figure 28.

In addition, if so, that is, other machines are waiting to acquire the lock, machine X indicates that the lock is now taken by the next machine in the queue, as shown in step 204, and then the confirmation of the transfer lock is obtained. The machine in the queue in step 205 is then removed from the queue of the waiting machine, as shown in step 206.

There are several different ways or specific embodiments for coordinating, reconciling, and cohering the basic concepts of correcting synchronization instances (or other mutually exclusive operations or operators) to coordinate operations between complex machines M1...Mn. Synchronization (or other mutually exclusive) job concepts, methods, and procedures can be implemented or implemented.

In a first embodiment, a particular machine, such as machine M2, loads the asset (e.g., category or object), which includes a synchronization example, fixes it, and then loads the modified asset (or category or object) Enter M1, M3, ... Mn (which may be sequential or simultaneous, or according to any other order, example or procedure) on each of the other machines, with corrections to the synchronization example containing the new correction Asset (or category or object). Please note that there may be one or more instances corresponding to only one object in the application code, or a plurality of instances corresponding to a plurality of objects in the application code. Please note that in a specific embodiment, the synchronized instance loaded is a binary executable object code. In addition, the synchronization example loaded is an executable intermediate code.

In this configuration, the term "master/controller" can be used, and each controlled (or secondary) machine M1, M3, ... Mn loads the corrected object (or category) and contains Newly modified by the master (or primary) machine (eg machine M2, or some other machine, such as machine X in Figure 15) on the computer communication network or other communication link or path Synchronization example. In some minor changes to this "master/controller" or "primary/secondary" configuration, the computer communication network may be replaced by a shared storage device, such as a shared file system, or a shared File/file storage area, such as a shared database.

Please note that the corrections performed on each machine or computer are not required and often not the same or similar. What is needed is that they are modified in a sufficiently similar manner, and in accordance with the innovative principles described herein, each step of the plurality of machines performs consistently and harmonically for the other machines described herein. Homework and purpose. Furthermore, it will be appreciated from the description provided herein that there are numerous ways in which modifications can be implemented, such as depending on the particular hardware, architecture, operating system, application code, or the like or other factors. It will also be appreciated that embodiments of the present invention may or may not have the benefit of being within an operating system, or within any operating system, within an EPROM, in a software, firmware, or It is implemented in any combination of these.

In another variation of the "master/controller" or "primary/secondary" configuration, machine M2 loads an asset (such as a category or object) containing one (or even one or more) initialization instances. , in uncorrected form on machine M2, and then (for example, machine M2 or each local machine) correct the category (or object or asset) by removing the synchronization from the asset (or category or object) in whole or in part A modified version of the asset is loaded by a computer communication network or other communication link or path, which has a synchronized version of the current correction or deletion on other machines. Therefore, when the correction is not a conversion, test, translation or compilation of the asset synchronization example, the synchronization example is deleted on all but one of all machines.

The entire process of deleting the synchronization instance may be performed by the "master" machine (e.g., machine M2 or some other machine, such as machine X of Fig. 15) or by each of the other machines M1, M3, ..., Mn is executed when the uncorrected asset is received. Additional changes to this "master/controlled" or "primary/secondary" configuration are to use a shared storage device, such as a shared file system, or a shared file/archive repository, such as a share A database for exchanging codes of the asset, category or object (including, for example, the modified code) between the machines M1, M2, ..., Mn and the machine X of the selective Fig. 15.

In still other embodiments, each machine M1, . . . , Mn receives the uncorrected asset (eg, category or object), including one or more synchronization instances, but corrects the example, and then Load an asset (such as a category or object) that contains a current modified example. While a machine (e.g., the master or primary machine) can customize or perform a different correction to a synchronized instance delivered to each machine, this embodiment can immediately make minor corrections made by each machine. Different, and improved, customized, and/or optimized based on their specific machine architecture, hardware, processor, memory, configuration, operating system, or other factors, yet still similar, reconciled, and consistent with other machines All other similar corrections and features need not necessarily be similar or identical.

In another configuration, a particular machine (e.g., M1) loads the uncorrected asset (e.g., category or object), which includes one or more synchronization instances, and all other machines M2, M3, ..., Mn performs a correction or deletion of the synchronization instance of the asset (eg, category or object) and loads the revised version.

In all of the specific embodiments described, the asset code (eg, a category code or an object code) is supplied or transmitted to the machines M1, . . . Mn, and a machine X of FIG. 15 is included as needed. Branching, decentralizing or transmitting between any combination or arrangement of different machines; for example by providing direct machine-to-machine communication (eg, supplying each M1, M3, M4, etc. directly from M2), or by providing or using a serial connection Or serial communication (eg, M2 supplies M1, which then supplies M3, then M4, and so on), or the combination of direct and concatenated and/or serial.

In still another configuration, the machines M1 through Mn can transmit some or all of the loading requirements to an additional machine X (see, for example, the specific embodiment of Figure 15), which can perform the correction of the application code 50, Including one (and possibly plural) initialization routines, which pass any of the above methods, and return the modified application code, including the current modified initialization equation for each machine M1 to Mn, and these machines are sequentially The modified application code is loaded, including a local modified example. In this configuration, machines M1 through Mn transfer all load requests to machine X, which returns a modified application code 50 to each machine, which includes a modified synchronization pattern. Such modifications performed by machine X may include any modifications encompassed by the scope of the invention. This configuration can of course be applied to some of the machines and other configurations described herein before being applied to other machines.

Those skilled in the art will be aware of a variety of possible techniques that can be used to modify computer code including, but not limited to, testing, program conversion, translation, or compilation means.

One such technique is to modify the application code without requiring a prior or subsequent change in the language of the application code. Another such technique is to convert the source code (eg, JAVA language source code) into an intermediary representation (or intermediate code language or virtual code), such as a JAVA byte code. Once this conversion occurs, the byte code is corrected and the conversion can be reversed. This provides the results needed for the modified JAVA code.

Another possible technique is to convert the application to machine code, either directly from the source code, or through the aforementioned intermediate language, or through some other intermediary means. The machine code is then corrected before being loaded and executed. Another such technique is to convert the source code into an intermediary representation, thus being modified and subsequently converted to machine code.

The present invention encompasses all of these correction procedures, as well as combinations of two, three or even more such programs.

Specific embodiments including memory management and copy object initialization, finalization, and synchronization

Structures, programs, computer programs and tools, and other aspects and features of a multiple computer system and computing method, which utilize at least one memory management and copy object initialization, finalization, and synchronization, It is immediately understood that these may also be needed, but are preferably applied in any combination.

It can also be appreciated that the memory management, initialization, finalization, and/or synchronization aspects of the present invention can be implemented or applied serially or sequentially or in parallel. For example, where the code is being scrutinized or analyzed to identify or detect a particular code segment for initialization, the same analysis or scrutiny may also attempt to identify or detect a code segment regarding finalization (or, for example, synchronization). In addition, individual sequential (or possibly overlapping) analysis and scrutiny can be used to individually detect codes for initialization and finalization and synchronization. Any modifications required for the code may also be performed in combination or independently, and further, portions may be performed collectively while other portions are executed independently.

Now that the memory management and replication, initialization, finalization, and synchronization aspects have been described, attention is now directed to an exemplary work scenario in which the application is consistent on both computers. A sexually harmonized way to execute the same application at the same time.

In this regard, please note Figures 31-33 showing two laptops 101 and 102. The computers 101 and 102 need not be identical, and in fact they may be an IBM or IBM replica and the other may be an APPLE computer. The computers 101 and 102 have two screens 105, 115, two keyboards 106, 116, but only a single mouse 107. The two machines 101, 102 are interconnected by a single coaxial cable or twisted pair cable 314.

Two simple applications are downloaded to each of the machines 101, 102, and the programs are modified so that they are loaded as described above. In this embodiment, the first application is a simple computer program and causes an image of a computer 108 to be displayed on the screen 105. The second program is a drawing program that displays blocks 109 of four colors, which are of different colors, and are randomly moved within a rectangular block 310. Again, after loading, the block 310 is displayed on the screen 105. Each application operates independently, so the blocks 109 are randomly moved on the screen 105, however the numbers in the computer 108 can be selected along with a mathematical operator (e.g., addition or multiplication) (using the mouse 107) So the computer 108 displays the result.

The mouse 107 can be used to "grab" the block 310 and move it to the right across the screen 105 and onto the screen 115 to arrive at the condition illustrated in Figure 32. In this configuration, the computer application is executed on machine 101, however the drawing application causes the display at block 310 to be on machine 102.

However, as shown in Fig. 33, it is possible to drag the computer 108 to the right by the mouse 107, as shown in Fig. 32, whereby a portion of the computer 108 is provided by each screen 105, 115. display. Similarly, the block 310 can be dragged to the left by the mouse 107, as shown in Fig. 32, so the block is partially displayed by each of the screens 105, 115, as shown in Fig. 33. In this configuration, the portion of the computer operation is being executed on a portion of machine 101 and machine 102, however, part of the drawing application is in progress with machine 101 and the remainder is performed on machine 102.

other instructions

The foregoing description is only illustrative of specific embodiments and modifications of the invention, and it will be understood by those skilled in the art that the invention can be practiced without departing from the scope of the invention. For example, reference to JAVA includes both the JAVA language and the JAVA platform and architecture.

In all of the illustrated illustrative examples, where the application code 50 was previously modified, or during loading, or even after loading but before the execution of the unmodified application code has been performed, it is understood that the correction is known. The application code is loaded to replace and execute to replace the uncorrected application code, and then to the corrections to be performed.

In addition, in the case that the correction occurs after the loading and after the execution of the unmodified application code has been performed, it is understood that the unmodified application code can be replaced by the entire modified application code, corresponding to the ongoing execution. The correction, or otherwise the uncorrected application code, may be partially replaced, or incrementally implemented as an application code that is to be gradually unmodified in the execution. Regardless of how these correction procedures are used, subsequent amendments to be executed are executed to replace the uncorrected application code.

The benefit of using a universal identification item as described in the present invention is in the form of all similarly synchronized local objects (or categories or assets or resources or the like) on each of the plurality of machines M1, ..., Mn. "meta-name" or "meta-identity". For example, in addition to having to trace each unique local name or identification of each similarly equivalent local object on each of the plurality of equivalent objects, it may additionally be defined or used corresponding to the plurality of machines on each machine. a generic name like the equivalent object (such as "globalname7787"), and know that each machine associates the common name to a specific local name or object (such as "globalname7787" corresponding to the object "localobject456" on machine M1, and corresponds to "globalname7787" of the object "localobject885" on the machine M2, and "globalname7787" corresponding to the object "localobject111" on the machine M3, etc.).

Those skilled in the programming field will know that when additional code or instructions are inserted into an existing code or instruction set to correct the same, existing code or instruction set, additional corrections will be required (eg, By renumbering the sequence of instructions, offsets, branches, attributes, notes, and the like can be satisfied.

Similarly, in the JAVA language, memory locations include, for example, field and array types. The above description deals with the fields, and the changes required for the array pattern are essentially the same appropriate corrections. Meanwhile, the invention can equally be applied to similar stylized language (including procedural, object-oriented and declaring of) to JAVA, including Microsoft.NET platform and architecture (Visual Basic, Visual C / C + +, and C #) FORTRAN, C /C ^{+ +} , COBOL, BASIC, etc.).

The JAVA code for updating the memory location or field value in the aforementioned configuration is modified based on the assumption that the execution time system (such as JAVA HOTSPOT VIRTUAL MACHINE written in C and JAVA) or the operating system (for example, in C and combined language) Written as LINUX). Each of its machines M1...Mn will typically update the memory on the local machine (eg M2), but not on any other machine (M1, M3...Mn). It is possible to leave the JAVA code, which can update the memory location or the unmodified field value, and additionally modify the LINUX or HOTSPOT instance to update the memory locally, so it is correspondingly updated on all other machines. The memory on it. In order to include such a configuration, the term "update transfer modality" as used herein is used in conjunction with memory that maintains substantially the same machine M1...Mn, which can be understood to be included in its range while the JAVA putfield and putstatic instructions And related operations, and the "combination" of the JAVA putstatic and putstatic and the LINUX or HOTSPOT code paragraph to perform memory update.

In the foregoing specific embodiment, the code of the JAVA initialization example is modified based on the assumption that the execution time system (such as JAVA HOTSPOT VIRTUAL MACHINE written in C and JAVA) or the operating system (for example, written in C and combined language) LINUX), each machine M1...Mn will call the JAVA initialization example. It is possible not to revise the JAVA initialization example, and otherwise modify the LINUX or HOTSPOT instance to call the JAVA initialization example, so if the object or category has already been loaded, the JAVA initialization instance will not be called. In order to include such a configuration, the term "initialization routine" is understood to include both a JAVA initialization routine and a "combination" of the JAVA initialization instance with the LINUX or HOTSPOT code segment within its scope, which will call or initialize the JAVA initialization example.

In the foregoing specific embodiment, the code of the JAVA finalization or clearing example is modified based on the assumption that the execution time system (such as JAVA HOTSPOT VIRTUAL MACHINE written in C and JAVA) or the operating system (for example, C and the combined language written in LINUX), each machine M1...Mn will call the JAVA finalization example. It is possible not to revise the JAVA finalization example, but to modify the LINUX or HOTSPOT instance, which will call the JAVA finalization example, so if the object or category is not to be deleted, the JAVA finalization example Will not be called. In order to include such a configuration, the term "finalization" is to be understood to include both the JAVA finalization modality and the "combination" of the JAVA finalization modality with the LINUX or HOTSPOT code segment within its scope, which will call Or initialize the JAVA finalization example.

The code of the JAVA synchronization example is modified in the foregoing specific embodiment, and the system is based on the assumption that the execution time system (such as JAVA HOTSPOT VIRTUAL MACHINE written in C and JAVA) or the operating system (for example, in C and combined language) Write LINUX), each machine M1...Mn will usually get the lock on the local machine (such as M2), but not on any other machine (M1, M3...Mn). It is possible to leave the JAVA synchronization example unmodified, and to revise the LINUX or HOTSPOT instance that obtains the lock locally, so it correspondingly also obtains the lock on all other machines. In order to include such a configuration, the term "synchronization example" is understood to include both a JAVA synchronization instance and a "combination" of the JAVA synchronization pattern and the LINUX or HOTSPOT code segment within its scope. Perform lock acquisition and release.

The terms and categories used herein are derived from the JAVA environment and include similar terms derived from different environments, such as dynamic link libraries (DLLs), or object code packages, or functional units or memory locations.

Various means are described with respect to specific embodiments of the present invention, including, but not limited to, locking means, decentralized execution time means, corrector or correction means, transfer means, distributed update means, counter means, synchronization means, and the like. By. In at least one embodiment of the present invention, any one or each of these various means may be implemented by computer code descriptions or instructions (which may include a plurality of computer code descriptions or instructions), which may be in a computer logic circuit, Execution within a processor, ASIC, microprocessor, microcontroller, or other logic to modify the operation of such logic or circuitry to perform the recited operations or functions. In another embodiment, any or each of these various means can be implemented as a firmware, and in other embodiments these can be implemented as a hardware. Furthermore, in at least one embodiment of the invention, any or each of these various means can be implemented by a combination of computer software, firmware and/or hardware.

Any or each of the foregoing methods, procedures and/or programs may preferably be implemented as a computer program and/or computer program product, and may be stored on any tangible medium or in an electronic, signal or digital position. form. The computer program or computer program product includes instructions and/or organized into modules, programs, sub-examples, or in any other manner for execution in processing logic, such as in a processor, or a computer or computer. In a microprocessor of a machine or information appliance; the computer program or computer program product corrects the operation of the computer, wherein the computer is executed or executed on a computer, coupled to, connected to, or otherwise communicated with the computer Computer program or computer program product. The computer program or computer program product corrects the operation and architectural structure of the computer, computer machine and/or information appliance to change the technical operation of the computer and achieve the technical effects described herein.

Accordingly, the present invention may comprise a computer program product comprising a set of program instructions stored on a storage medium, or electronically stored in any form, and operable to allow a plurality of computers to execute any method, program, or example. Or similar, as described herein, and included in any of the scope of the patent application.

Furthermore, the present invention can include a plurality of computers interconnected by a communication network or other communication link or path, each of which performs the same or different portions of an application code substantially simultaneously or simultaneously. , which is written to work only on a single computer on a different part of the computer, where the computer is programmed to perform any of the methods, procedures, or examples described in this specification, or Anyone who claims to be in the scope of the patent application or who is loaded with a computer program product.

The term "comprising" (and variations of its grammar) as used herein is used to mean "having" or "including" and does not exclude the exclusive meaning of "including".

Copyright notice

This patent specification and appendices form part of it, which contains copyrighted content. The copyright owner (ie, the applicant) does not refuse to reproduce the patent specification or related content from publicly available related patent office files for review purposes, but retains all related copyrights. In particular, such instructions cannot be entered into a computer without the specific written permission of the copyright owner.

appendix

A, B, C, D

Appendix A

The following is a list of programs in the JAVA language:

A1. This first excerpt is a part of the illustration of the correction code of the corrector 51 according to steps 92 and 103 of FIG. It searches the code array of the entire application code 50, and when it detects a memory manipulation instruction (ie, a write static instruction (opcode 178) in the JAVA language and the virtual machine environment), it inserts an "alert" instance. To fix the application code.

A2. This second excerpt is part of the DRT.alert() method, which implements step 125 and arrow 127 of Figure 12. The DRT.alert() method requires one or more threads of the DRT processing environment of Figure 12 to update and communicate the value and identification of the changed memory location corresponding to the job of Appendix A1.

A3. This third excerpt is part of the DRT 71, which corresponds to step 128 of Figure 12. This code segment shows the DRT in a separate thread, such as thread 12/1 of Figure 12, after the notification or request at step 125 and array 127, and transmits the changed value across the network 53. And the changed numerical position/identification to other machines of the plurality of machines M1...Mn.

A4. This fourth excerpt is part of DRT 71 and corresponds to steps 135 and 136 of Figure 13. This is a section of the code that receives the identification and value pairing of the transfer transmitted by the other DRT 71 over the network and writes the changed value to the identified memory location.

// START

A5. This fifth excerpt is a compiled form of one of the example.java applications of Appendix A7, which performs a memory manipulation job (putstaic and putfield).

A6. This sixth excerpt is a compiled version of the decoding of the same exemplary application in Appendix A5, which is based on the modification performed by FieldLoader.java of Appendix A11, which is based on Figure 9 of the present invention. These amendments are highlighted in bold .

A7. The seventh excerpt is used in the excerpts A5 and A6. The source code of the example.java application. This sample application has two memory locations (staticValue and instanceValue) and performs two memory location jobs.

}

A8. The eighth excerpt is the source code of FieldAlert.java, which corresponds to step 125 and arrow 127 of FIG. 12, and it is required to execute the thread 121/1 of FieldSend.java of the "decentralized execution time" 71. Pass a changed value and identify the pairing to other machines M1...Mn.

A9. The ninth excerpt is the FieldSend.java source code corresponding to step 128 of Figure 12, and waits for a request/notification generated by FieldAlert.java corresponding to step A15 and arrow A127 of A8, and it passes through the network. 53 Pass the value/identification pair changed by FieldAlert.java.

A10. The tenth excerpt is the source code of FieldReceive.java, which corresponds to steps 135 and 136 of Figure 13, and receives the change value transmitted by the field 53 via FieldSend.java of Appendix A9 and Identify the pairing.

A11. FieldLoader.java.

This excerpt is the source code of FieldLoader.java, which fixes an application code, such as the example.java application code in Appendix A7, when it is loaded into a sequence according to steps 90, 91, 92, 103, and 94 of Figure 10. When on JAVA virtual machine. FieldLoader.java utilizes the abuse categories of Appendix A12 through A36 during the revision of a compiled JAVA.

A12. Attribute_info.java

Used to represent the appropriate category of the attribute_info structure within ClassFiles.

A13. ClassFile.java

Used to represent the appropriate category of the ClassFile structure.

A14. Code_attribute.java

Used to represent the appropriate category of the Code_attribute structure within ClassFiles.

A15. CONSTANT_Class_info.java

Used to represent the appropriate category of the CONSTANT_Class_info structure within ClassFiles.

A16. CONSTANT_Double_info.java

Used to represent the appropriate category of the CONSTANT_Double_info structure within ClassFiles.

}

A17. CONSTANT_Fieldref_info.java

Used to represent the appropriate category of the CONSTANT_Fieldref_info structure within ClassFiles.

A18. CONSTANT_Float_info.java

Used to represent the appropriate category of the CONSTANT_Float_info structure within ClassFiles.

A19. CONSTANT_Integer_info.Java

Used to represent the appropriate category of the CONSTANT_Integer_info structure within ClassFiles.

A20. CONSTANT_InterfaceMethodref_info.java

Used to represent the appropriate category of the CONSTANT_InterfaceMethodref_info structure within ClassFiles.

}

A21. CONSTANT_Long_info.java

A suitable category for representing the CONSTANT_Long_info structure within ClassFiles.

A22. CONSTANT_Methodref_info.java

A suitable category for representing the CONSTANT_Methodref_info structure within ClassFiles.

A23. CONSTANT_NameAndType_info.java

A suitable category for representing the CONSTANT_NameAndType_info structure within ClassFiles.

A24. CONSTANT_String_info.java

Used to represent the appropriate category of the CONSTANT_String_info structure within ClassFiles.

}

A25. CONSTANT_Utf8_info.java

Used to represent the appropriate category of the CONSTANT_Utf8_info structure within ClassFiles.

A26. ConstantValue_attribute.java

A suitable category for representing the ConstantValue_attribute structure within ClassFiles.

A27. cp_info.java

Used to represent the appropriate category of the cp_info structure within ClassFiles.

A28. Deprecated_attribute.java

Used to represent the appropriate category of the Deprecated_attribute structure within ClassFiles.

}

A29. Exceptions_attribute.java

A suitable category for representing the Exceptions_attribute structure within ClassFiles.

}

A30. field_info.java

Used to represent the appropriate category of the field_info structure within ClassFiles.

}

A31. InnerClasses_attribute.java

Used to represent the appropriate category of the InnerClasses_attribute structure within ClassFiles.

A32. LineNumberTable_attribute.java

Used to represent the appropriate category of the LineNumberTable_attribute structure within ClassFiles.

Import java.lang.*;

A33. LocalVariableTable_attribute.java

A suitable category for representing the LocalVariableTable_attribute structure within ClassFiles.

A34 .method_info.java

Used to represent the appropriate category of the method_info structure within ClassFiles.

A35. SourceFile_attribute.java

Used to represent the appropriate category of the SourceFile_attribute structure within ClassFiles.

Import java.lang.*;

A36. Synthetic_attribute.java

A suitable category for representing Synthetic_attribute structures within ClassFiles.

Appendix B

Appendix B1 is an excerpt from the pre-correction of the compiled form of the decoding of the <clinit> method of the example.java application of Appendix B9. Appendix B2 is the revised form of Appendix B1, which is modified by InitLoader.java of Appendix B10 according to the steps in Figure 20. Appendix B3 is an excerpt from the revision of the compiled form of the decoding of the <init> method of the example.java application of Appendix B9. Appendix B4 is the revised form of Appendix B3, and the steps according to Figure 21 are corrected by InitLoader.java of Appendix B10. Appendix B5 is another modified form of Appendix B1, which is modified by InitLoader.java in Appendix B10 according to the steps in Figure 20. And Appendix B6 is another modified form of Appendix B3. The steps according to Figure 21 are corrected by InitLoader.java of Appendix B10. These corrections are highlighted in bold .

B1

B2

B3

B4

B5

B6

Appendix B7

This excerpt is the source code of InitClient.java, which corresponds to steps 171, 172, 173, 174, 175 and 176 of FIG. 17, and steps 181 and 182 of FIG. 18, and queries an "initialization server", such as machine X of FIG. It executes InitServer.java in Appendix B8 to determine the initialization state of the relevant category or object that is being sought to be initialized.

Appendix B8

This excerpt is the source code of InitServer.java, which corresponds to steps 191, 192, 193, 194, 195 and 196 of Figure 19, which operates on an "initialization server", such as machine X of Figure 15, and receives the complex part from network 53. An "initialization state requirement" of a plurality of objects or categories specified by one of the equivalent objects or categories on the machine M1...Mn, transmitted by the InitClient.java machine executing Appendix B7, and returned in response to the specified The corresponding initialization state of the category or object.

Appendix B9

This excerpt is an excerpt of the source code of the example.java application used in the excerpts B1-B6 before/after the correction. This example application has two initialization instances <clinit> and <init>, which are modified according to the invention by InitLoader.java of Appendix B10.

}

Appendix B10

InitLoader.java

This excerpt is the source code of InitLoader.java, which fixes an application code, such as the example.java application code of Appendix B9, when it is according to steps 161-164 of Figure 16, and 201-204 of Figure 20, and Steps 201, 212, 213 and 204 of Fig. 21 are loaded onto a JAVA virtual machine. InitLoader.java utilizes the abuse categories of Appendix A12 through A36 during the revision of a compiled JAVA.

Appendix C

Appendix C1 is an excerpt from the pre-correction of the compiled form of the decoding of the finalize() method of the example.java application of Appendix C4. Appendix C2 is the revised form of Appendix C1, which is corrected by the procedure of Figure 22 using FinalLoader.java in Appendix C7. Appendix C3 is another post-correction form of Appendix C1, which is modified by the procedure of Figure 22 in Final Loader.java of Appendix C7. These amendments are highlighted in bold .

C1. Typical prior art finalization of a single machine

C2. Better finalization of multiple machines

C3. Better finalization of multiple machines (other solutions)

Appendix C4

This excerpt is an excerpt of the source code of the example.java application used in the excerpts C1-C3 before/after the correction. This example application has a single finalization example that is modified according to the present invention by FinalLoader.java of Appendix C7.

Appendix C5

This excerpt is the source code of FinalClient.java, which corresponds to steps 171, 172A, 173A, 174A, 175A and 176A of Fig. 23, and queries an "initialization server", such as machine X of Fig. 15, which executes the appendix C6's InitServer.java, which determines the finalization status of the relevant category or object that is sought to be finalized.

Appendix C6

This excerpt is the source code of FinalServer.java, which corresponds to steps 191A, 192A, 193A, 194A, 195A, 196A and 197A of Figure 25, which operate on a "finalization server", such as the machine of Figure 15. X, and receiving a "clear state request" from the network 53 for a plurality of objects or categories specified by one of the equivalent objects or categories on the plurality of machines M1...Mn, and by executing the FinalClient.java machine of Appendix C5 The corresponding finalized state of the specified category or object is transmitted and returned.

Appendix C7

FinalLoader.java

This excerpt is the source code of FinalLoader.java, which fixes an application code, such as the example.java application code of Appendix C4, when it is loaded into a JAVA according to steps 161A, 162A, 163B and 164A of Figure 22. When on a virtual machine. FinalLoader.java utilizes the abuse categories of Appendix A12 through A36 during the revision of a compiled JAVA.

Appendix D1

Appendix D1 is an excerpt from the revision of the decoding and compilation form of the synchronization operation of example.java of Appendix D3, which includes a start "monitorenter" instruction and an end "monitorexit" instruction. Appendix D2 is the form after the amendment of Appendix D1, as amended by LockLoader.java in Appendix D6 of the steps in Figure 26. These corrections are highlighted in bold .

Appendix D2

Method void run()

Appendix D3

This excerpt is the source code of the example.java application used before/after the correction of the excerpts D1 and D2. This sample application has a single synchronization job instance that includes a start "monitorenter" instruction and an end The "monitorexit" instruction, which is modified according to the invention by the LockLoader of Appendix D6.

Appendix D4

This excerpt is the source code of LockClient.java, which corresponds to steps 171B, 172B, 173B, 174B, and 175B of FIG. 27, and steps 181B, 182B, 183B, 184B, and 185B of FIG. 28, and the query is " Synchronization server, such as machine X of Figure 15, which performs LockServer.java of Appendix D5, thereby synchronizing (ie, pairing by a lock and release lock request) to seek related categories or objects to be synchronized ( That is, seeking to be "locked").

Appendix D5

This excerpt is the source code of LockServer.java, which corresponds to 191B, 192B, 193B, 194B, 195B, 196B, 197B and 198B of FIG. 29, and steps 201, 202, 203, 204, 205, 206, 207 and 208 of FIG. 30, which are in a "synchronized servo" Work on the machine, such as machine X in Figure 15, and receive one of the plurality of objects or categories specified in one of the equivalent items or categories on the plurality of machines M1...Mn from the network 53 "Getting the lock request" Or a "release lock request" and transmitted by the machine executing LockClient.java of Appendix D4, and responding to return a corresponding confirmation of the ownership of a "lock-up request", or as needed for the specified category or object Confirmation of "release lock request".

Appendix D6

LockLoader.java

This excerpt is the source code of LockLoader.java, which fixes an application code, such as the example.java application code of Appendix D3, when it is loaded into a JAVA according to steps 161B, 162B, 163B and 164B of Figure 26 When on a virtual machine. LockLoader.java utilizes the abuse categories of Appendix A12 through A36 during the revision of a compiled JAVA file category.

1. . . Single machine

2. . . Central processing unit

3. . . Memory

4. . . Busbar

5. . . Screen

6. . . keyboard

7. . . mouse

12. . . CPU

13. . . General purpose memory

14. . . network

50. . . application

50A. . . category

50X. . . First object

50Y. . . Second object

50Z. . . Third object

51. . . Corrector

53. . . network

61. . . Java virtual machine

71. . . Decentralized execution time

72. . . Java virtual machine

75. . . arrow

83. . . arrow

101. . . computer

102. . . computer

105. . . Screen

106. . . keyboard

107. . . mouse

108. . . computer

109. . . Block

115. . . Screen

116. . . keyboard

120. . . Processing environment

121. . . Thread

310. . . Rectangular square

314. . . Twisted pair cable

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS A specific embodiment of the present invention will now be described with reference to the drawings, wherein: FIG. 1 is an internal architecture diagram of a conventional computer; FIG. 2 is an internal architecture diagram of a known symmetric multiprocessor; An architectural diagram of a distributed computing operation; FIG. 4 is an architectural diagram of a network operation using a cluster of conventional use; and FIG. 5 is a block diagram of an architecture of a plurality of machines operating the same application according to the first embodiment of the present invention; Figure 6 is a block diagram of a prior art computer for operating a JAVA code to form a JAVA virtual machine; Figure 7 is similar to Figure 6, but is illustrated in accordance with the preferred embodiment. The initial loading of the code; Figure 8 is similar to Figure 5, but illustrates the interconnection of the plurality of computers, each of which operates the JAVA code in the manner illustrated in Figure 7; Figure 9 shows the network in the Figure 9 A flowchart of an exemplary program after loading the same application period on each machine in the road; FIG. 10 is a flowchart showing a modification procedure of FIG. 9; and FIG. 11 is a memory update A first embodiment of the machine of Figure 8 Figure 12 is an architecture diagram similar to the 11th diagram, but illustrates another embodiment; FIG. 13 illustrates an exemplary multi-thread memory update of the computer of FIG. 8; Figure 14 shows the architecture of a computer configured to work in a JAVA code, and thereby constitutes a JAVA virtual machine; Figure 15 shows the n machines that execute the application, and is composed of an additional server machine. Schematic diagram of the X service; Figure 16 shows the flowchart of the modification of the initialization example; Figure 17 shows the flow chart of the initialization or suspension of the initialization example; Figure 18 shows the transmission to the server machine. Flowchart of the query of X; Figure 19 is a flow chart showing the response of the server machine X of the request of Fig. 18; and Fig. 20 is the initialization of the correction of the class of the initial asset type <clinit> A flow chart of the example; FIG. 21 is a flow chart showing the initialization example of the modification of the asset type <init> instruction of the object; and FIG. 22 is a flow of the modification of the "clearing" or finalization example. Figure; Figure 23 shows the continuation or abort of the finalization Flowchart; Figure 24 is a flow chart showing the query transmitted to the server machine X; Figure 25 is a flow chart showing the response of the server machine X of the request of Figure 24; A flowchart for the correction of the entry and exit of the routine; FIG. 27 is a flow chart of the processing after the processing machine requests to acquire a lock; and FIG. 28 is a flow chart for requesting release of a lock; Figure 5 is a flow chart showing the response of the server machine X requested in Figure 27; Figure 30 is a flow chart showing the response of the server machine X requested in Figure 28; Figure 31 is the interconnection The two laptops simultaneously execute the architecture diagram of the multiple applications, two of which are executed on a single computer; the 32nd image is similar to the 31st, but the device shown in Figure 31 has an application in each The operation on the computer; and Figure 33 is similar to the 31st and 32nd, but shows that the two applications on the device of Figure 31 work on both computers at the same time.

50‧‧‧Application

53‧‧‧Network

71‧‧‧Distributed execution time

72‧‧‧Java Virtual Machine

83‧‧‧ arrow

Claims (44)

A method of operating an application in a multiple computer system, the multiple computer system comprising a plurality of single computers interconnected via a communication link, the application having code written to include a plurality of threads, the plurality of threads It is intended to be executed on a single stand-alone computer with reference to the single stand-alone computer having a single central processing unit (CPU) or symmetric multi-processing unit and a single independent local memory, the single independent local memory not being And sharing with any other computer of the plurality of single computers, the method comprising the steps of: (a) allocating the plurality of threads of the application code in the plurality of single computers interconnected to include the application code At least a portion of the application of the at least one first thread is distributed on a first particular one of the plurality of single computers, and at least one second thread of the application code is assigned to the plurality of single Performing on one of the second specific users of the computer; (b) operating each single computer, making the single independent The memory location of the memory can only be addressed by assigning the thread or threads executing thereon; (c) by executing such a single computer with one of the application code threads or threads for execution The application code thread or the threads allocated; (d) generating a similar plurality of memories of each of the plurality of single computers before or during the performing step a body position, each of the plurality of memory locations having a name, wherein the named memory location value content of each of the named memory memories is the same at the time of generation; (e) During or after the execution step, the single independent local memory of the single computer stores the value of each application memory that can be addressed by the thread or threads allocated for execution by the single computer. An original version; (f) transmitting, via the communication link, one of each of the new original versions of each of the application memory values, the one of the duplicate versions, to the other independent local memory of all of the plurality of single computers Body, wherein each application memory has overwritten a previous corresponding application memory value due to execution of the thread or threads on any of the single computers; and (g) at all of the plurality of single computers The single independent local memory stores the copied version of each of the transmitted and updated individual application memory values; (h) locks the memory location of each of the individual computers, wherein Authorizing a lock on one of the multiple computer systems to utilize one of the memory locations of one of the memory locations to allow for the utilization of the memory location and preventing all others of the single computer from utilizing the license lock release Corresponding to the memory location; (i) the stored application memory values of all of the single computers remain the same for a communication link update transmission delay, and none of the single computers are allocated Thread or line The independent local memory that addresses any other of the plurality of single computers during execution, the stored application memory values including the original versions and the replicated versions; and (j) when all such plurals When a single computer no longer needs to refer to the corresponding memory location, all of the original versions and duplicate versions of the same memory locations are deleted together. The method of claim 1, further comprising the step of: establishing a memory location on the one of the single computers if the application running on one of the single computers is established The object is transmitted via the communication network to all others of the plurality of single computers. The method of claim 2, further comprising the steps of: modifying the application before, during, or after loading, and modifying the application to create a memory location by inserting an initialization instance For example, the initialization example propagates each object created by a single computer to all of these other single computers. The method of claim 1, further comprising the step of providing a decentralized runtime component to each of the plurality of computers for communicating between the plurality of single computers via the communication network. The method of claim 4, further comprising the following Step: providing a shared form that can be accessed by each of the distributed execution time components, and wherein the identification of any one of the plurality of single computers that no longer need to access a memory location is stored with the memory Identification of location. The method of claim 5, further comprising the step of associating a counter component with the shared form, the counter component storing one of the number of the single computers that no longer need to access the memory location count. The method of claim 6, further comprising the step of providing an additional computer on which the sharing program is not executed and hosting the shared form and counter, the additional computer being connected to the communication network. The method of claim 4, further comprising the steps of: providing a shared form accessible by each of the distributed execution time components, and wherein storing the memory location currently required to access Identification of any of a plurality of single computers and identification of the location of the memory. The method of claim 8, further comprising the step of associating a counter component with the shared form, the counter The component stores one of the counts of the number of such single computers seeking access to the location of the memory. The method of claim 9, further comprising the steps of: providing an additional computer on which the sharing program is not executed, and hosting the shared table and the counter component storing the count, the additional computer being connected to The communication network. The method of claim 1, wherein the transmitting step comprises the step of performing an update propagation example. The method of claim 11, wherein the step of performing the update propagation example comprises the steps of: transmitting an updated, altered or manipulated memory location identification, and manipulating the memory location Updated, manipulated, or altered value or content. The method of claim 12, wherein the update communication is performed via a low speed network communication link or path. The method of claim 11, wherein each of the plurality of single computers receiving an update communication from the network writes the received memory location value to the corresponding received recognized memory location The local independent memory location. The method of claim 13, wherein the communication link comprises a communication link through the Internet. The method of claim 13, wherein the low-speed network is one of a communication speed that is one size slower than a work speed of the bus of the single computer. The method of claim 11, wherein the communication between the single computers is controlled by the single computer machine hardware, but is a discrete running time of each of the individual computers. Controlled by (DRT), the decentralized runtime coordinates the specific communications between the plurality of individual computers. The method of claim 17, wherein the DRT coordinates the communication between the single computers to be independent in transmission, protocol, and communication links. The method of claim 11, wherein: reading of the memory location or data from the local independent memory of the single computer can be satisfied locally because all (or all of the subsets) memory locations are One of the current values is stored on the single computer carrying the processing of the threads that generate the request to read the memory; and all memory locations or data from the local independent memory of the single computer can be written Locally satisfied, since all (or all of the subsets) of one of the memory locations are currently stored on the single computer carrying the processing of the code threads that generated the request to write to the memory; The need to rewrite the memory is relatively lower than the requirement of the read memory, so the memory location can be continuously updated at a relatively slow rate via a slow and inexpensive commercial network, however, the relatively slow The rate is sufficient for the application written to the memory. A multiple computer system comprising: a plurality of single computers interconnected via a communication link; wherein each of the plurality of single computers has: (a) a single central processing unit (CPU) or a symmetric multiple processing unit, (b) a single independent local memory that is not shared with any other computer of the plurality of single computers, and (c) is independent of the other of the plurality of single computers; Each of the plurality of single computers is adapted to store at least one thread that is similar to a copy of one of the applications, the application having code written to operate on only a single computer system, the code including all intended a plurality of threads executed by a single memory; wherein each of the single independent local memories has a thread or a thread or address that can only be accessed by a corresponding single computer executing a corresponding copy of the application code Memory location, and each of the single independent local memories has all of the threads stored thereon from all of the plurality of computers Executing all of the application memory values formed; (i) an allocation component for allocating or receiving one of the plurality of threads of the stored application code of the plurality of single computers, And causing at least a portion of the application comprising at least one thread of the application code to be distributed to one of the plurality of single computers by one or more of the plurality of single computers carried out; (ii) an execution component for executing the application code thread or threads by the plurality of single computers having one of the application code threads or threads assigned; (iii) a memory storage The memory storage for storing individual individual addresses of each of the threads of each of the plurality of individual computers in the single independent local memory of each of the plurality of individual computers One of the application memory values is copied; (iv) a transfer component for communicating each new application memory value to the single independent local of all others of the plurality of single computers via the communication link Memory, such that the values of the duplicate application memory values of all of the single computers remain substantially the same for an update transmission delay, wherein each new application memory value has been on any of the single computers The execution of the application code overwrites a previous corresponding value; (v) a locking member that can be applied to the single computer, wherein one of the memory is intended to be utilized Any single computer in the location obtains an authorization lock from the locking member to permit the utilization of the memory location and prevent all other users of the single computer from utilizing the corresponding memory location before the authorization lock is released; (vi Deleting a component for collectively deleting all of the same memory locations when each of the plurality of single computers no longer needs to refer to the corresponding memory location. The system of claim 20, wherein the locking member comprises an acquisition locking example and a release locking example, and two examples Both include fixes to the application running on all of these computers. The system of claim 21, wherein the locking member further comprises a shared list listing each of the named memory locations, the memory locations, and the memory locations used by the computer One of the lock states and any waiting for a lock to get one of the queues. The system of claim 22, wherein the locking member is located in an additional computer that does not run the application and is connected to the communication network. The system of claim 20, wherein each of the computers includes a decentralized runtime component, the decentralized runtime component of each of the computers being capable of communicating with all other computers Enabling the memory location to be dispersed by the one of the computers if a portion of the application running on one of the computers establishes a memory location on the one of the computers The runtime component is propagated to all others of the computer. The system of claim 20, wherein each of the computers includes a decentralized runtime component, the decentralized runtime component of each of the computers being capable of communicating with all other computers Having a portion of the application running on one of the computers no longer need to refer to one of the memory locations of the one of the computers, the identification of the memory location not referenced by the computer The decentralized runtime component is passed to a shared list that can be accessed by all of the other computers. The system of claim 20, wherein each of the applications is modified before, during, or after loading, and the application is modified by inserting an initialization instance to establish a memory location. As an illustration, the initialization example will propagate each item newly created by a computer to all of these other computers. The system of claim 26, wherein the application is modified according to a program selected from the group of programs, the program group includes recompilation at load time, precompilation before loading, and Compile before compiling, compiling in time, and recompiling after loading and before executing the relevant part of the application. The system of claim 26, wherein the modified application is transferred to all of the computers according to a program selected from the group, the group comprising a master/controlled transfer, a branch Transfer and concatenation transfer. The system of claim 20, wherein the local memory capacity allocated to each of the applications is substantially the same, and the overall memory capacity available to each of the applications is The memory capacity allocated. The system of claim 29, wherein all of the computers comprise a decentralized update component, each of the distributed update components communicating via the communication link, and the data transfer rate is substantially less than the local memory Volume read rate. The system of claim 30, wherein at least some of the computers are manufactured by different manufacturers and/or have different operations. Industry system. The system of claim 20, wherein the communication link comprises an internet communication link. The system of claim 20, wherein the communication component comprises means for performing an update propagation example. The system of claim 33, wherein the means for performing an update propagation example comprises identifying an updated, altered or manipulated memory location, and manipulating the memory A component of an updated, manipulated, or altered value or content of a location. The system of claim 34, wherein the means for updating communications is operative to perform via a low speed communication link or path. The system of claim 33, wherein each of the plurality of single computers receiving an update communication from the network writes the received memory location value to a corresponding received recognized memory location The local independent memory location. The system of claim 35, wherein the communication link comprises a communication link through the Internet. The system of claim 35, wherein the low speed network is one of a communication speed that is one size slower than a working speed of the bus of the single computer. The system of claim 33, wherein the communication between the single computers is controlled by the single computer machine hardware, but is distributed by each of the individual computers. Controlled by the DRT, the decentralized runtime coordinates the specific communications between the plurality of individual computers. The system of claim 39, wherein the DRT coordinates the communication between the single computers in terms of transmission, agreement, and link. The system of claim 33, wherein: reading of all memory locations or data from the single computer local independent memory can be satisfied locally because all (or all of the subsets) memory locations are One of the current values is stored on the single computer carrying the processing of the code threads that generate the request to read the memory; and all memory locations or data from the local independent memory of the single computer can be written. Satisfied locally, since all (or all of the subsets) of one of the memory locations are currently stored on the single computer hosting the processing of the code threads that generated the request to write to the memory; Or the requirement to rewrite the memory is relatively lower than the requirement of the read memory, so the memory location can be continuously updated at a relatively slow rate via a slow and inexpensive commercial network, however, the relative The slow rate is sufficient for the application written to the memory. A computer program product stored on a physical machine readable medium and including executable instructions for implementing a method of operating an application in a multiple computer system, the multiple computer system The system includes a plurality of single computers interconnected via a communication link, the application having code written to include a plurality of threads, the plurality of threads being intended to be executed on a single independent computer and referring to the single independent computer, A single stand-alone computer has a single central processing unit (CPU) or symmetric multi-processing unit and a single independent local memory that is not shared with any other computer of the plurality of single computers, such executable instructions Executing a method, the method comprising the steps of: (a) allocating the plurality of threads of the application code in the plurality of interconnected single computers, such that the at least one first thread including the application code At least a portion of the application is distributed on a first particular one of the plurality of single computers, and at least one second thread of the application code is assigned to one of the plurality of single computers Execute; (b) operate each single computer so that the memory location of the single independent local memory can only be used by Configuring the thread or threads to be executed thereon; (c) executing the allocated application code thread or the single computer having the application code thread or thread assigned for execution And (d) generating a similar plurality of memory locations for each of the plurality of single computers prior to or during the performing step, each of the plurality of memory locations having a name in which the named memory is located at the beginning of each of the memories The memory location value content is the same when the system is generated; (e) during the execution step or after the execution step, the single independent local memory storage of the single computer by the single computer can be allocated for execution. One of the original versions of each of the application memory values addressed by the thread or the threads; (f) one of each of the new original versions of each of the application memory values transmitted via the communication link is updated to the And the single independent local memory of all others of the plurality of single computers, wherein each application memory has overwritten a previous corresponding application memory due to execution of the thread or threads on any of the single computers And (g) storing the replicated version of each of the individual application memory values passed and updated in the single independent local memory of all of the plurality of single computers; (h) locking the single computer The memory location of each of the multiple computer systems that utilize one of the memory locations to obtain an authorized lock to allow the memory location Utilizing, and preventing all other users of the single computer from utilizing the corresponding memory location before the authorization lock is released; and (i) storing the application memory values of all of the single computers for a communication chain The node updates the transmission delay while remaining the same, without any of the single computers storing the independent local memory of any other of the plurality of single computers during the execution of the thread or the execution of the threads, The application memory values include The original version and the duplicate version; and (j) when all of the plurality of single computers no longer need to refer to the corresponding memory location, collectively deleting all of the original and duplicate versions of the same memory location . The computer program product of claim 42, wherein the transmitting step comprises the step of performing an update propagation example, and the step of executing the update propagation example comprises the steps of: transmitting the updated, changed or The identification of the manipulated memory location and the updated, manipulated or altered value or content of the manipulated memory location, and the updated communication is performed via a low speed network communication link or path, the low speed network The communication link or path is a communication communication speed having a size smaller than that of the bus of the single computer; each of the plurality of single computers receiving an update communication from the network The memory location value received is written to the local independent memory location corresponding to the received recognized memory location; the communication between the single computers is guided by the single computer hardware. Controlled by one of each individual computer's Decentralized Run Time (DRT), which coordinates the specific pass between the plurality of single computers The DRT coordinates the communication between the single computers in terms of transmission, protocol and link; all memory locations or data from the local independent memory of the single computer can be read locally because all Or all The current value of one of the subsets of memory locations is stored on the single computer carrying the processing of the threads that execute the request to read the memory; and all memory locations from the local independent memory of the single computer Or the writing of the data may be satisfied locally, as all (or all of the subsets) of the memory locations are currently stored in the single computer carrying the processing of the threads that execute the request to write to the memory. And the need to write or rewrite the memory is relatively lower than the requirement of the read memory, so the memory location can be continuously and slowly at a relatively slow rate via a slow and inexpensive commercial network. The update is successful, however, the relatively slow rate is sufficient to meet this need for applications written to memory. The computer program product of claim 42, wherein the code is written to include a plurality of threads, the plurality of threads being intended to be executed on a single independent computer and referring to the single independent computer, the single The stand-alone computer has a single central processing unit (CPU) or symmetric multi-processing unit and a single independent local memory that is not shared with any other computer of the plurality of single computers.