System and apparatus for dynamically upgrading concentrated executable computer software code

In upgrading a concentrated executable computer code with an upgrade code, indexed lists are created for the concentrated code and for the upgrade code. The indexed lists have index references for code identifiers of code structures in the concentrated code and the upgrade code, respectively. The indexed lists are stored in a virtual table. The concentrated code is integrated with the upgrade code to form an integrated code. The virtual table contains an operable part referable by the integrated code such that when a code structure being executed originates from the concentrated code the indexed list for the concentrated code is stored in the operable part of the virtual table, and when a code structure being executed originates from the upgrade code the indexed list for the upgrade code is stored in the operable part of the virtual table.

FIELD OF THE INVENTION

The present invention relates to a system and apparatus for dynamically upgrading concentrated executable computer software code. The invention is particularly useful in upgrading bytecode and computer software written in an object-oriented language, such as JAVA.

DICTIONARY

The following dictionary is to be used in interpreting this specification:“bytecode” is computer software code.“class”, or “classes”, are code segments that contain method definitions and field specifications.“comprise”, or variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.“electronic communications network” or “ECN” will be understood to include any computing, multimedia or video system in which a user can remotely access or receive transmissions of bytecode.“field” is a component of an object in which object data are stored as integers or characters, i.e., variables.“identifier” means a reference to the name of a unique class, method or field.“instance”, when used in the context of data, refers to data associated with an object.“method” is code used to perform a particular task, such as modifying data in some way, such as for performing a procedure or a function.“object” is a collection of fields and methods that operate on fields. An object is also an instance of a class.“private”, when used in the context of data, refers to data generally accessible by a single class.“public”, when used in the context of data, refers to data accessible by multiple classes.“static”, when used in the context of data, refers to data associated with each class.

BACKGROUND OF THE INVENTION

In U.S. Pat. No. 6,163,780, Hewlett-Packard Company of Palo Alto, Calif., describes a system for concentrating executable computer software code. This system involves parsing the computer software code by means of concentrating software. The concentrating software achieves this by a series of scans of the computer software code.

The first scan identifies all unique classes referenced in the computer software code and includes the identifier of each such class into a “ClassList”. The second scan searches for all unique methods (the identifiers of which are stored in a “MethodList”) and the third scan searches for all unique Fields (the identifiers of which are stored in a “FieldList”).

Every class identified in the ClassList is then scanned to determine whether there are references to further classes not recorded in the ClassList. If so, then the identifier for such classes is added to the ClassList. The process is then repeated in relation to the newly added classes. In this manner, all unique classes referenced in the computer software code are identified in the ClassList.

Once this scan has been completed, every class in the ClassList is again scanned, but this time to determine any further methods not recorded in the MethodList. If a method is found that is not included in the MethodList, then the identifier for the method is added to the MethodList. The process continues until all classes in the ClassList have been scanned for further methods.

A further scan is used to identify all further fields not included in the FieldList and add their identifier to the FieldList. This scan involves traversing all classes in the ClassList and every method in these classes to identify further fields.

The ClassList, MethodList and FieldList are then each sorted and reformatted into a canonical list form. Each class, method and field in the ClassList, MethodList and FieldList, respectively, is also assigned a unique index reference (typically an integer corresponding to the position of the corresponding identifier within the appropriate canonical list).

Local data referenced by each method of each class are then stored in an array for each class. The local data reference in each method is then replaced with the index value of the location of the local data in the array. The computer software code can then be executed with class, method and field invocations being resolved as part of the execution process.

The problem with this arrangement is that the use of index references to corresponding canonical lists hinders upgrading of the computer software code. To elaborate, the computer software code is in concentrated form while, typically, the upgrade bytecode will not. However, if the upgrade bytecode is in concentrated form, there is no guarantee that the canonical lists formed from concentration of the upgrade bytecode will be compatible with the canonical lists formed from concentration of the computer software code. There is also no mechanism for allowing the computer software code to be dynamically upgraded.

Accordingly, there is a need to allow concentrated computer software code to be dynamically upgraded without the need to reconcentrate the computer software code.

SUMMARY OF THE INVENTION

An object of the present invention is to provide a system for dynamically upgrading concentrated bytecode. The present invention also provides a system and method for interpreting and executing a dynamically upgraded version of the concentrated bytecode.

It is another object of the present invention to provide a system and method for receiving bytecode comprising the upgrade, concentrating it, transmitting it via a computer network, such as the Internet, and integrating the concentrated bytecode comprising the upgrade with the original concentrated bytecode by means of a virtual table.

By providing a method and system for dynamically upgrading bytecode or computer code, the present invention alleviates to a great extent the need to reconcentrate bytecode or computer code when the bytecode or computer code needs to be upgraded. It also allows the bytecode to be upgraded “on-the-fly”.

In a preferred embodiment, list processing and indexing is used to create indexes of various code structures within an upgrade bytecode. Preferably, index listings for each of the code structures are created. The index listings contain listings of identifiers corresponding to the particular instances of the respective code structures in the upgrade bytecode and index references corresponding to each of the identifiers included in the listing. The upgrade bytecode is reduced in size by replacing identifiers representing code structures in the upgrade bytecode with the corresponding index references. The concentrated upgrade bytecode is then integrated with the original concentrated bytecode, and the index listings formed during concentration of the upgrade bytecode are added to the virtual table as a record. Amendments are made to other index listings included in the virtual table to facilitate execution of the upgrade bytecode in conjunction with the original computer software code.

More particularly, in an embodiment applicable to typical JAVA-based computer code, or bytecode, the data structures include classes, method and fields. Listings of the classes, methods and/or fields appearing in the JAVA bytecode are created by systematically reviewing the JAVA upgrade bytecode to identify each instance of a particular class, method and/or field, respectively. These listings are sorted to create respective canonical listings or indexes of the classes, methods and/or fields invoked in the upgrade bytecode. These listings include reference indicators such as index locations or pointers, assigned to each of the classes, methods and/or fields in the respective sorted lists. The JAVA upgrade bytecode is then revised so that the index locations of the classes, methods and/or fields replace the identifiers of the class, methods and/or fields invoked in the upgrade bytecode. The sorted lists are then added to the virtual table as a record and amendments made to previous index listings included in the virtual table to facilitate execution of the upgrade bytecode in conjunction with the original computer software code.

The present invention also provides an interpreter for use in conjunction with the combination of the concentrated upgrade bytecode and the concentrated original bytecode. The interpreter of the present invention can execute bytecode concentrated in accordance with the concentration method or system of the present invention when combined with the concentration method or system of the invention described in U.S. Pat. No. 6,163,780.

These and other features of the invention will be appreciated from review of the following detailed description of the invention, along with the accompanying figures, in which like reference characters refer to like parts throughout.

DETAILED DESCRIPTION OF THE INVENTION

In accordance with the present invention, a system and method are provided for dynamically upgrading concentrated executable computer software code. Such a system and method may be used in conjunction with various known computer languages and interpreters, including JAVA, various dialects of JAVA (such as the version available from Microsoft Corporation), and other languages.

As shown inFIG. 1, the bytecode the subject of the upgrade (referred to hereafter as the “upgrade bytecode”)74may be stored within a server system10, which is connected via an ECN20with user systems30. For example, the ECN20may include cable transmission networks, telephone networks, an intranet, the Internet, or combinations thereof. It will be understood that an ECN20as described herein may include a single server computer, such as a single bulletin board system.

As illustrated inFIG. 1, a plurality of server systems10may be connected to the ECN20and a plurality of user systems30may also be connected. The servers10may perform a number of functions including storing data and/or web page information and so on. In a preferred embodiment, at least one of the servers10has an associated memory15which stores the upgrade bytecode74and which can transmit the upgrade bytecode74via the ECN20to a user system30. As utilised in conjunction with the present invention, the server memory15stores a concentrated bytecode generated in accordance with the present invention. The server memory15may also store a concentrated bytecode generated in accordance with the invention disclosed by U.S. Pat. No. 6,163,780 (as discussed below). The concentrated upgrade bytecode74may be transmitted via the ECN20to a user system30. Preferably, the user system30contains an API for integrating the concentrated upgrade bytecode74with the concentrated original bytecode72and an interpreter or other associated tool for receiving the integrated concentrated bytecode76and executing it. The concentrated upgrade bytecode74generated in accordance with the present invention may be generated on a data processing system40as illustrated inFIG. 2. Typical data processing systems which may be used include personal computers, work stations, palm computers, personal digital assistants (PDAs) or even mainframe computers. Also, multiple systems coupled in a computer network, with data files shared among systems on the network, may be employed. Data processing systems can be used to practice the present invention utilising a variety of operating systems (such as for example, Windows™, Windows NT™, Windows 95™, Windows XP™, Sun OS™, OS/2™ and Macintosh OS™) and programming languages.

As illustrated inFIG. 2a typical data processing system40includes a central processing unit (CPU)50. The CPU50is optionally connected via a bus60to, among other things, a volatile memory65(eg. a RAM), non-volatile memory70(such as disk drives, CD-ROMs, flash memory, or data tape), a network communications interface75(such as a modem, T1line interface, ISDN modem or cable modem), a user input device or devices80(such as keyboard and/or a pointing or point-and-click device such as a mouse, light pen, touch screen, touch pad), a user output device or devices87(such as a video display screen and/or an audio speaker), and a removable media drive90(such as a floppy disk drive, CD-ROM drive, PCMCIA device, CD-WORM drive or data tape drive). The data processing system40can be a personal computer (PC).

The data processing system40may be a free standing system, providing upgrade bytecode74concentrated in accordance with the present invention to a server10for transmission over the ECN20. Alternatively, a server10may comprise the data processing system40. Alternatively, the data processing system40may be in communication with user systems30via the ECN20. In another embodiment, the data processing system40may receive upgrade bytecode74, concentrate it on-the-fly in accordance with the present invention and then transmit it as such to a server10, or to another system via the ECN20.

Although the method and system of the present invention can be used to great advantage within a networked system, as in the illustrated embodiment, it should be clear that the code concentrating method and system of the present invention can also be used to advantage in non-networked computer systems.

The upgrade bytecode74to be concentrated in accordance with the present invention can be stored in the RAM65, the non-volatile memory70, or on the removable media90. The upgrade bytecode to be concentrated may also be transmitted on-the-fly to the data processing system40, which in turn concentrates the upgrade bytecode on-the-fly and re-transmits the concentrated upgrade bytecode74. In the illustrated embodiment, the upgrade bytecode74to be concentrated is stored in the non-volatile memory70. In some applications, it may be desirable to store the bytecode72in RAM for increased access speed.

The data processing system40also executes and preferably stores concentrating software95for concentrating the upgrade bytecode74in accordance with the present invention. The concentrating software95is illustrated inFIG. 2as being stored in non-volatile memory70. However, it should be understood that it can be stored in other ways such as in RAM65or on removable media inserted in the removable media drive90. Exemplary removable media for storing the concentrating software95(which may be in any form, such as source code, compiled or binary versions) are illustrated inFIGS. 3A,3B and3C as floppy disks, magnetic tape and optical disks, respectively. In the preferred embodiment, the concentrating software95is read into RAM65when it is to be executed. To concentrate the upgrade bytecode74, the concentrating software95is executed.

To provide a full understanding of the present invention, U.S. Pat. No. 6,163,780 is incorporated herein by reference. However, while the process described in that disclosure is almost identical to the process that forms part of the present invention, in the present invention the resulting canonical lists (referred to in this specification as “OriginalClassList”, “OriginalMethodList” and “OriginalFieldList” respectively) contain a field for recording the unique identifier of the item the subject of the canonical list and a field for identifying the offset of the class, method or field, as appropriate, from the start of the original bytecode72(the “Offset Field”). To illustrate, when the original bytecode72is loaded into RAM65the first memory address taken up by the original bytecode72is recorded. The value of the Offset Field for each entry in the OriginalClassList, OriginalMethodList and OriginalFieldList is then calculated by determining the distance, in memory address terms, between the first memory address taken up by the original bytecode72and the first memory address taken up by the bytecode that forms the basis of the class, method or field, as appropriate.

The process described in U.S. Pat. No. 6,63,780 is shown schematically inFIGS. 4 to 10.

Once concentrated, ideally, the OriginalClassList, OriginalMethodList and OriginalFieldList consists of abstract or minimal canonical lists of classes, methods and fields. In this situation, the abstract or minimal lists are kept separate from the lists stored in a virtual table92(described in more detail below and first shown inFIG. 18). In alternative arrangements, the OriginalClassList, OriginalMethodList and OriginalFieldList may be stored in their complete form as a record in the virtual table92or split such that the set of abstract or minimal canonical lists of classes, methods and fields is kept separate from the virtual table92while the remainder is stored as a record in the virtual table92. In either case the original bytecode is adapted to refer to the abstract or minimal canonical list (if any) as well as the virtual table92.

Once the original bytecode72has been processed in the manner described above, an upgrade can then be made without the need for reconcentration of the original bytecode72by adopting the following process.

As shown inFIG. 11, the upgrade process commences with an initialisation procedure1000. The initialisation process1000consists of a single step1010where three lists corresponding respectively to classes, methods and fields are initialised to some default state, such as empty. The lists in the illustrated embodiment are referred to hereafter as “UpgradeClassList”, “UpgradeMethodList” and “UpgradeFieldList”. Note that the lists are used as exemplary data structures, but any suitable data structure may be used.

A pointer to the start of each list is then created and initialised. These pointers will be referred to hereafter as “ClassListStart”, “MethodListStart” and “FieldListStart” as appropriate. At the same time, additional pointers to the end of each list are created and initialised. These pointers will be referred to hereafter as “ClassListEnd”, “MethodListEnd” and “FieldListEnd” as appropriate.

The process then continues to Phase1as indicated by step1020.

In Phase1,1020the upgrade bytecode74is scanned and the UpgradeClassList populated. This commences with step1030, when the upgrade bytecode74is scanned for any class definitions or invocations. When a class definition or invocation is found, a check is made to determine whether the class has already been recorded in the UpgradeClassList. If it is determined that the class has not already been recorded in the UpgradeClassList, the name of the class defined or invoked is inserted, into the UpgradeClassList and ClassListEnd updated to point to the newly inserted class. If it is determined that the class has already been recorded in the UpgradeClassList, the scan for the next class definition or invocation continues.

In this manner, the UpgradeClassList ultimately generated contains the names of each of the classes that are defined or invoked within the upgrade bytecode74and ClassListEnd points to the last class inserted into the UpgradeClassList.

Any procedure for scanning the upgrade bytecode74may be used.

At step1040, a first class is retrieved from the UpgradeClassList and a variable UC is filled with the name corresponding to that first class. In successive iterations of step1040, variable UC is assigned the name of successive classes listed in the UpgradeClassList and each class is processed in accordance with the steps that follow.

Variable UC thereby indicates the class that is currently being processed, and such class is referred to herein as “Class UC”.

Upon reaching the end of the UpgradeClassList, the variable UC is assigned an “end-of-list” value (e.g., a null value) indicating that there are no more classes in the UpgradeClassList to be processed. If it is determined, at step1050, that variable UC has been assigned a null value, processing continues to the next phase, Phase2,1140. If UC has not been assigned a null value, thereby indicating that there are more classes to be processed, operation continues to step1060.

At step1060, Class UC is scanned to determine whether any other classes are defined or invoked therein. The distinction between a class definition and a class invocation is determined with reference to its context. To elaborate, a class definition will be prefaced by the reserved word or phrase necessary to define the class. In the JAVA programming language, for example, the reserved word used to indicate that a new class has been defined is “class”.

Upon identification of a class definition or invocation, the name of the class so defined or invoked is assigned to a variable UD. Further, if the identified class is a newly defined class, this fact is recorded by setting boolean variable DefinedClass to true (this variable initialised to false at first instance). If the scan of Class UC does not reveal any classes that are defined or invoked within Class UC, variable UD is assigned a null value.

In successive iterations of step1060, variable UD is assigned the name of the next class defined or invoked within Class UC, if any. If Class UC does not reference any further classes defined or invoked within the upgrade bytecode74, variable UD is assigned a null value.

Processing then continues at step1070where the value assigned to variable UD is analysed. If variable UD has been assigned a null value, processing returns to step1040where the next class identified in the UpgradeClassList is processed. If variable UD has been assigned any value other than a null value, processing moves to step1080.

Step1080compares the value of variable UD, ie. the name of the class defined or invoked in the upgrade bytecode74, against the names of classes already included in the UpgradeClassList. If this comparison determines that the class name, as recorded by variable UD, has already been included in the UpgradeClassList, processing continues to step1090. If the comparison determines that the class name, as recorded by variable UD, has not already been included in the UpgradeClassList, processing continues to step1110.

At step1090, the value assigned to variable DefinedClass is analysed. If variable DefinedClass has been assigned a true value, processing continues to step1100. If variable DefinedClass has been assigned a false value, processing returns to step1060where the next class identified in UpgradeClassList is processed.

Step1100commences by searching the UpgradeClassList for the record corresponding to the class recorded by variable UD. Once found, the Offset Field value for this record is set by determining the distance, in memory address terms, between the first memory address taken up by the upgrade bytecode74and the first memory address taken up by the bytecode that defines the class recorded by variable UD. Variable DefinedClass is then reset to a false value. Processing then returns to step1060.

At step1110, the class name, as recorded by variable UD, is added to the UpgradeClassList at the position immediately after the class pointed to by ClassListEnd. At step1120, the value assigned to variable DefinedClass is analysed. If variable DefinedClass has been assigned a true value, processing continues to step1130. If variable DefinedClass has been assigned a false value, processing returns to step1060where the next class identified in UpgradeClassList is processed.

At step1130, the Offset Field value for the class recorded by variable UD is calculated. This is achieved by determining the distance, in memory address terms, between the first memory address taken up by the upgrade bytecode74and the first memory address taken up by the bytecode that defines the class recorded by variable UD.

Processing then returns to step1060.

FIG. 12illustrates the steps involved in Phase2,1140. Phase2,1140involves scanning the upgrade bytecode74and populating the UpgradeMethodList with initially defined or identified methods. This phase commences with step1150, where the upgrade bytecode74is scanned for any method definitions or invocations.

When a method definition or invocation is found, a check is made to determine whether the method has already been recorded in the UpgradeMethodList. If it is determined that the method has not already been recorded in the UpgradeMethodList, the name of the method defined or invoked is inserted, into the UpgradeMethodList, and MethodListEnd updated to point to the newly inserted method. If it is determined that the method has already been recorded in the UpgradeMethodList, the scan for the next method definition or invocation continues.

In this manner, the UpgradeMethodList ultimately generated contains the names of each of the methods that are defined or invoked within the upgrade bytecode74and MethodListEnd points to the last method inserted into the UpgradeMethodList.

Any procedure for scanning the upgrade bytecode74may be used.

Processing then continues at step1160where the UpgradeClassList is reset to its start, i.e., the class pointed to be ClassListStart. The first class in the UpgradeClassList is then retrieved, at step1170, and variable UC assigned the name corresponding to that first class.

In successive iterations of step1170, variable UC is assigned the name of successive classes listed in the UpgradeClassList and each class is processed in accordance with the steps that follow. Variable UC thereby indicates the class that is currently being processed, and, as above, such class is referred to as “Class UC”.

Upon reaching the end of the UpgradeClassList, the variable UC is assigned an “end-of-list” value (e.g., a null value) indicating that there are no more classes in the UpgradeClassList to be processed. If it is determined at step1180, that variable UC has been assigned a null value, processing continues to Phase3,1270. If UC has not been assigned a null value, thereby indicating that there are more classes to be processed, operation continues to step1190.

In step1190, Class UC is scanned to determine whether any other methods are defined or invoked therein. The distinction between a method definition and a method invocation is determined with reference to its context. To elaborate, a method definition will be prefaced by the reserved word or phrase necessary to define the method. In the JAVA programming language, for example, the reserved word used to indicate that a new method has been defined is “method”.

Upon identification of a method definition or invocation, the name of the method so defined or invoked is assigned to a variable UM. Further, if the identified method is a newly defined method, this fact is recorded by setting boolean variable DefinedMethod to true (this variable initialised to false at first instance). If the scan of Class UC does not reveal any methods that are defined or invoked within Class UC, variable UM is assigned a null value.

In successive iterations of step1190, variable UM is assigned the name of the next method defined or invoked within Class UC, if any. If Class UC does not reference any further methods defined or invoked within the upgrade bytecode74, variable UM is assigned a null value.

Processing then continues at step1200where the value assigned to variable UM is analysed. If variable UM has been assigned a null value, processing returns to step1190where the next class identified in the UpgradeClassList is processed. If variable UM has been assigned any value other than a null value, processing moves to step1210.

Step1210compares the value of variable UM, ie. the name of the method defined or invoked in the upgrade bytecode74, against the names of methods already included in the UpgradeMethodList. If this comparison determines that the method name, as recorded by variable UM, has already been included in the UpgradeMethodList, processing continues to step1220. If the comparison determines that the method name, as recorded by variable UM, has not already been included in the UpgradeMethodList, processing continues to step1240.

At step1220, the value assigned to variable DefinedMethod is analysed. If variable DefinedMethod has been assigned a true value, processing continues to step1230. If variable DefinedMethod has been assigned a false value, processing returns to step1190where the next class identified in UpgradeClassList is processed.

Step1230commences by searching the UpgradeMethodList for the record corresponding to the method recorded by variable UM. Once found, the Offset Field value for this record is set by determining the distance, in memory address terms, between the first memory address taken up by the upgrade bytecode74and the first memory address taken up by the bytecode that defines the method recorded by variable UM.

Variable DefinedMethod is then reset to a false value. Processing then returns to step1190.

At step1240, the method name, as recorded by variable UM, is added to the UpgradeMethodList at the position immediately after the method pointed to by MethodListEnd. At step1250, the value assigned to variable DefinedMethod is analysed.

If variable DefinedMethod has been assigned a true value, processing continues to step1260. If variable DefinedMethod has been assigned a false value, processing returns to step1190where the next class identified in UpgradeClassList is processed.

At step1260, the Offset Field value for the method recorded by variable UM is calculated. This is achieved by determining the distance, in memory address terms, between the first memory address taken up by the upgrade bytecode74and the first memory address taken up by the bytecode that defines the method recorded by variable UM.

Processing then returns to step1190.

Once all method definitions have been found, as indicated by variable UC having been assigned a null value when analysed at step1170, processing continues to Phase3,1270, to facilitate population of the UpgradeFieldList.

FIG. 13. Illustrates the steps involved in Phase3,1270. Phase3,1270, involves scanning the upgrade bytecode74and populating the UpgradeFieldList with initially identified fields (typically public fields). This phase commences with step1280, where the upgrade bytecode74is scanned for any reserved words indicating that a new field has been defined or referenced.

As described above, any series of processing steps to scan the upgrade bytecode74may be employed.

The name of the newly defined field is then inserted into the UpgradeFieldList at the position immediately after the field pointed to be FieldListEnd and FieldListEnd updated to point to the newly inserted field. In this manner, the UpgradeFieldList ultimately generated contains the name of each of the fields that are defined or referenced within the upgrade bytecode74. Processing then continues at step1290.

At step1290, UpgradeClassList is reset to its start, i.e., the class pointed to be ClassListStart. The first class in the UpgradeClassList is then retrieved, at step1300, and variable UC assigned the name corresponding to that first class.

In successive iterations of step1300, variable UC is assigned the name of successive classes listed in the UpgradeClassList and each class is processed in accordance with the steps that follow. Variable UC thereby indicates the class that is currently being processed, and, as above, such class is referred to as “Class UC”.

Upon reaching the end of the UpgradeClassList, the variable UC is assigned an “end-of-list” value (e.g., a null value) indicating that there are no more classes in the UpgradeClassList to be processed. If it is determined at step1310, that variable UC has been assigned a null value, processing continues to Phase4,1510. If UC has been assigned any value other than a null value, thereby indicating that there are more classes to be processed, operation continues to step1320.

In step1320, Class UC is scanned to determine whether any other fields are defined or referenced therein. The distinction between a field definition and a field reference is determined with reference to its context. To elaborate, a field definition will be prefaced by the reserved word or phrase necessary to define the field. Such reserve words or phrases may vary according to the programming language of the upgrade bytecode74.

Upon identification of a field definition or reference, the name of the field so defined or referenced is assigned to a variable UF. Further, if the identified field is a newly defined, this fact is recorded by setting boolean variable DefinedField to true (this variable initialised to false at first instance). If the scan of Class UC does not reveal any fields that are defined or referenced within Class UC, variable UF is assigned a null value.

In successive iterations of step1320, variable UF is assigned the name of the next field defined or referenced within Class UC, if any. If Class UC does not reference any further fields defined or referenced within the upgrade bytecode74, variable UF is assigned a null value.

Processing then continues at step1330where the value assigned to variable UF is analysed. If variable UF has been assigned a null value, processing continues at step1400. If variable UF has been assigned any value other than a null value, processing moves to step1340.

Step1340compares the value of variable UF, i.e., the name of the field defined or referenced in the upgrade bytecode74, against the names of fields already included in the UpgradeFieldList. If this comparison determines that the field name, as recorded by variable UF, has already been included in the UpgradeFieldList, processing continues to step1350. If the comparison determines that the field name, as recorded by variable UF, has not already been included in the UpgradeFieldList, processing continues to step1370.

At step1350, the value assigned to variable DefinedField is analysed. If variable DefinedField has been assigned a true value, processing continues to step1360. If variable DefinedField has been assigned a false value, processing returns to step1320where the next field identified in UpgradeFieldList is processed.

Step1360commences by searching the UpgradeFieldList for the record corresponding to the field recorded by variable UF. Once found, the Offset Field value for this field is set by determining the distance, in memory address terms, between the first memory address taken up by the upgrade bytecode74and the first memory address taken up by the bytecode that defines the field recorded by variable UF. Variable DefinedField is then reset to a false value. Processing then returns to step1320.

At step1370, the field name, as recorded by variable UF, is added to the UpgradeFieldList at the position immediately after the field pointed to by FieldListEnd. At step1380, the value assigned to variable DefinedField is analysed. If variable DefinedField has been assigned a true value, processing continues to step1390. If variable DefinedField has been assigned a false value, processing returns to step1320where the next class identified in UpgradeClassList is processed.

At step1390, the Offset Field value for the field recorded by variable UF is calculated. This is achieved by determining the distance, in memory address terms, between the first memory address taken up by the upgrade bytecode74and the first memory address taken up by the bytecode that defines the field recorded by variable UF.

Processing then returns to step1320.

This process repeats until all fields defined or referenced in Class UC have been identified.

At step1400, Class UC is rest to its start. A scan is then commenced, at step1410, of Class UC for any method invocations. When a method invocation is found, the name of the method invoked is assigned to variable UM. If Class UC does not include any method invocations, variable UM is assigned an “end-of-list” value, such as a null value.

In successive iterations of step1410, variable UM is assigned the name of successive method invocations in Class UC and each method is processed in accordance with the steps that follow. Variable UM thereby indicates the method that is currently being processed, and such method will be referred to herein as “Method UM”.

At step1420, the value of variable UM is analysed to determine whether it has been assigned a null value. If variable UM has been assigned a null value, processing returns to step1300where the next class in the UpgradeClassList is processed. If variable UM has been assigned any value other than a null value, processing continues to step1430.

At step1430, method UM is scanned to determine the next defined or referenced field. The first of any such fields referenced is assigned to a variable UF. If the scan of Method UM does not reveal any field references, or any further field references, variable UF is assigned a null value.

In successive iterations of step1430, variable UF is assigned the name of the next field defined or referenced within Method UM. If Method UM does not refer to any further fields, variable UF is assigned a null value.

Processing then continues at step1440where the value of variable UF is analysed. If variable UF is assigned a null value, processing continues at step1430where the next method defined or referenced in Class UC is identified. If variable UF is assigned any value other than a null value, processing moves to step1450.

Step1450compares the value of variable UF, ie. the name of the field defined or referenced in the upgrade bytecode74, against the names of fields already included in the UpgradeFieldList. If this comparison determines that the field name, as recorded by variable UF, has already been included in the UpgradeFieldList, processing continues to step1460. If the comparison determines that the field name, as recorded by variable UF, has not already been included in the UpgradeFieldList, processing continues to step1480.

At step1460, the value assigned to variable DefinedField is analysed. If variable DefinedField has been assigned a true value, processing continues to step1480. If variable DefinedField has been assigned a false value, processing returns to step1430where the next method identified in UpgradeMethodList is processed.

Step1470commences by searching the UpgradeFieldList for the record corresponding to the field recorded by variable UF. Once found, the Offset Field value for this field is set by determining the distance, in memory address terms, between the first memory address taken up by the upgrade bytecode74and the first memory address taken up by the bytecode that defines the field recorded by variable UF. Variable DefinedField is then reset to a false value. Processing then returns to step1430.

At step1480, the field name, as recorded by variable UF, is added to the UpgradeFieldList at the position immediately after the field pointed to by FieldListEnd. At step1490, the value assigned to variable DefinedField is analysed. If variable DefinedField has been assigned a true value, processing continues to step1500. If variable DefinedField has been assigned a false value, processing returns to step1430where the next method identified in UpgradeMethodList is processed.

At step1500, the Offset Field value for the field recorded by variable UF is calculated. This is achieved by determining the distance, in memory address terms, between the first memory address taken up by the upgrade bytecode74and the first memory address taken up by the bytecode that defines the field recorded by variable UF.

Processing then returns to step1430.

This process repeats until all methods invoked in Class UC have been traversed to identify any field referenced and all field references in each such method, i.e., Method UM, have been identified and processed.

FIG. 14shows the steps that form Phase4,1510. Phase4, commences by sorting the UpgradeClassList to create a canonical form, as illustrated by step1520. Steps1530and1540are then processed to sort the UpgradeMethodList and UpgradeFieldList, respectively, to create canonical forms of each. Processing then proceeds to Phase5,1550(seeFIG. 15).

Phase5,1550commences at step1560by resetting UpgradeClassList such that reference is made to the first class included therein, i.e., to the class pointed to by ClassListStart. The first class in the UpgradeClassList is then retrieved, at step1570, and the variable UC filled with the name corresponding to that first class.

In successive iterations of step1570, variable UC is assigned the name of successive classes listed in the UpgradeClassList and each class is processed in accordance with the steps that follow. Variable UC thereby indicates the class that is currently being processed, and, as above, such class will be referred to as “Class UC”. Upon reaching the end of the UpgradeClassList, the variable UC is assigned an “end-of-list” value (e.g., a null value) indicating that there are no more classes in the UpgradeClassList to be processed. If it is determined, at step1580, that variable UC has been assigned a null value, processing continues to Phase6,1680. If UC has been assigned any value other than a null value, thereby indicating that there are more classes to be processed, operation continues to step1590.

Step1590comprises two actions. Firstly, an array of local constant data for Class UC is created. Secondly, the array is initialised to some default state such as empty. Subsequent iterations of step1590see a new array of local constant data being created and initialised, each new array being associated with the class then being processed, i.e., Class UC.

Processing then continues to step1600. At step1600, Class UC is scanned for a reference to a local constant data. When, and if, so found the name of the local constant data so referenced is assigned to variable UV. If Class UC contains no references to local constant data, variable UV is assigned a null value.

In successive iterations of step1600, variable UV is assigned the name of the next local constant data referenced within Class UC. If Class UC does not refer to any further local constant data, variable UV is assigned a null value.

Step1610involves the analysis of the value assigned to variable UV. If variable UV has been assigned a null value processing continues at step1610. If variable UV has been assigned any value other than a null value, processing continues to step1620.

At step1610, the value assigned to variable UV is saved in the array of local constant data created at step1590. The reference in Class UC to the local constant data is then replaced with the value representing the position in the array of local constant data where the value assigned to variable UV has been saved. Processing then returns to step1590.

Once all local constant data references in Class UC have been identified and saved in the array of local constant data, processing moves to step1620.

At step1620, Class UC is again reset to its start. A scan is then commenced, at step1630, of Class UC for any method invocations. When a method invocation is found, the name of the method invoked is assigned to variable UM. If Class UC does not include any method invocations, variable UM is assigned an “end-of-list” value, such as a null value.

In successive iterations of step1630, variable UM is assigned the name of successive method invocations in Class UC and each method is processed in accordance with the steps that follow. Variable UM thereby indicates the method that is currently being processed, and, as discussed above, such methods will be referred to as “Method UM”.

At step1640, the value of variable UM is analysed to determine whether it has been assigned a null value. If variable UM has been assigned a null value, processing returns to step1570where the next class in the UpgradeClassList is processed. If variable UM has been assigned any value other than a null value processing continues to step1650.

Step1650sees method UM scanned to determine the next local constant data reference. The first of any such references is assigned to a variable UV. If the scan of Method UM does not reveal any local constant data references, or any further local constant data references, variable UV is assigned a null value.

In successive iterations of step1650, variable UV is assigned the name of the next local constant data referenced within Method UM. If Method UM does not refer to any further local constant data, variable UV is assigned a null value.

Processing then continues at step1660where the value of variable UV is analysed. If variable UV is assigned a null value, processing returns to step1630where the next method invoked in Class UC is identified. If variable UV is assigned any value other than a null value, processing moves to step1670.

At step1670, the value assigned to variable UV is saved in the array of local constant data created at step1580. The reference in Class UC to the local constant data where the value assigned to variable UV has been saved. Processing then returns to step1650.

This process repeats until all methods invoked in Class UC have been traversed to identify any local constant data references and all local constant data references in each such method, i.e., Method UM, have been identified and saved in the array of local constant data for Class UC.

Phase6,1680, sees the classes, methods and fields defined and referenced in the upgrade bytecode74replaced with a reference to the appropriate entry in the appropriate canonical list. The phase commences with step1690and is illustrated inFIGS. 16 to 18.

Step1690commences by assigning the size, in memory address terms, of the concentrated original bytecode72to a variable OriginalBytecodeSize. Thereafter, the size, in memory terms, of the unconcentrated upgrade bytecode74is assigned to a variable UpgradeBytecodeSize. Processing then continues at step1700.

At step1700a linear scan of the upgrade bytecode74commences for classes, methods and fields. The first identified reference to a class, method or field is assigned to a variable CMF. Processing then continues at step1710.

At step1710, the value of variable CMF is analysed to determine whether the reference is to a class. If CMF does reference a class, processing continues to step1720. Otherwise, processing continues to step1750.

Step1720compares the value of variable CMF, ie. the name of the class, against the names of classes already included in the UpgradeClassList. If the comparison determines that the class name, as recorded by variable CMF, has been included in the UpgradeClassList, processing continues to step1730. If the comparison determines that the class name, as recorded by variable CMF, has not been included in the UpgradeClassList, an error is raised and appropriate error-handling procedures invoked at step1740.

At step1730, the reference to the class name replaced is with the index value of the corresponding class name in UpgradeClassList. For example, if the class name corresponded with the fifth entry in the UpgradeClassList, the reference to the class name would be replaced by the number 5. Processing then continues at step1840.

The value of variable CMF is further analysed, at step1750, to determine whether the reference is to a method. If CMF does reference a method, processing continues to step1760. Otherwise processing continues to step1790.

Step1760compares the value of variable CMF, i.e., the name of the method, against the names of methods already included in the UpgradeMethodList. If the comparison determines that the method name, as recorded by variable CMF, has been included in the UpgradeMethodList, processing continues to step1770. If the comparison determines that the method name, as recorded by variable CMF, has not been included in the UpgradeMethodList, an error is raised and appropriate error-handling procedures invoked at step1780.

At step1770, the reference to the method name is replaced with the index value of the corresponding method name in UpgradeMethodList in the same manner as a class reference is replaced at step1730. Processing then continues at step1840.

Again, the value of variable CMF is analysed, at step1790, to determine whether the reference is to a field. If CMF does reference a field, processing continues to step1800. Otherwise, an error is raised and appropriate error-handling procedures invoked at step1830.

Step1800compares the value of variable CMF, i.e., the name of the field, against the names of fields already included in the UpgradeFieldList. If the comparison determines that the field name, as recorded by variable CMF, has been included in the UpgradeFieldList, processing continues to step1810. If the comparison determines that the field name, as recorded by variable CMF, has not been included in the UpgradeFieldList, an error is raised and appropriate error-handling procedures invoked at step1820.

At step1810, the reference to the field name is replaced with the index value of the corresponding field name in UpgradeFieldList in the same manner as a class reference is replaced at step1730. Processing then continues at step1840.

It should be noted that replacing class names, method names and field names with index values will affect the size of the upgrade bytecode74. With the exception of the Offset Field for the first entry as processed at steps1700to1830above, this results in the Offset Field values for each defined class/method/field entry in their respective canonical list (i.e., UpgradeClassList, UpgradeMethodList and UpgradeFieldList) pointing to a memory address that does not correspond with the first memory address taken up by the defined class/method/field. Thus, there needs to be a means of correcting this error.

At step1840the linear scan of the upgrade bytecode74continues for further classes, methods and fields. When found, the class, method or field reference is assigned to the variable CMF. If the linear scan does not identify, at step1845, any further classes, methods or fields in the upgrade bytecode74, processing continues to Phase7,2040. Otherwise processing continues to step1850.

At step1850, the value of variable CMF is analysed to determine whether the reference is to a class. If CMF does reference a class, processing continues to step1860. Otherwise, processing continues to step1910.

Step1860compares the value of variable CMF, i.e., the name of the class, against the names of classes already included in the UpgradeClassList. If the comparison determines that the class name, as recorded by variable CMF, has been included in the UpgradeClassList, processing continues to step1870. If the comparison determines that the class name, as recorded by variable CMF, has not been included in the UpgradeClassList, an error is raised and appropriate error-handling procedures invoked at step1880.

At step1870, the reference to the class name is replaced with the index value of the corresponding class name in UpgradeClassList. Thereafter, at step1890, the Offset Field value for the class name is analysed. If the Offset Field value is set to its initialised value (such as a null value), processing returns to step1840where the linear scan resumes and the next class, method or field reference is processed.

If the Offset Field value is set to any value other than its initialised value, the Offset Field value is corrected at step1900. This correction is achieved by determining the then current size, in memory address terms, of the upgrade bytecode74and subtracting from that value the value recorded by UpgradeBytecodeSize. This results in a “difference” value that is the result of previous replacements. The Offset Field value then being processed is then “corrected” by adding this “difference” value to the current value of the Offset Field.

Additionally, the value recorded by OriginalBytecodeSize is added to the current value of the Offset Field (incorporating the “difference value”). The reason for this is explained in more detail below.

Processing then returns to step1840.

The value of variable CMF is further analysed, at step1910, to determine whether the reference is to a method. If CMF does reference a method, processing continues to step1920. Otherwise processing continues to step1970.

Step1920compares the value of variable CMF, ie. the name of the method, against the names of methods already included in the UpgradeMethodList. If the comparison determines that the method name, as recorded by variable CMF, has been included in the UpgradeMethodList, processing continues to step1930. If the comparison determines that the method name, as recorded by variable CMF, has not been included in the UpgradeMethodList, an error is raised and appropriate error-handling procedures invoked at step1940.

At step1930, the reference to the method name is replaced with the index value of the corresponding method name in UpgradeMethodList. Thereafter, at step1950, the Offset Field value for the method name is analysed. If the Offset Field value is set to its initialised value (such as a mill value), processing returns to step1840where the linear scan resumes and the next class, method or field reference is processed.

If the Offset Field value is set to any value other than its initialised value, the Offset Field value is corrected at step1960. This correction is achieved by determining the then current size, in memory address terms, of the upgrade bytecode74and subtracting from that value the value recorded by UpgradeBytecodeSize. This results in a “difference” value that is the result of previous replacements. The Offset Field value then being processed is then “corrected” by adding this “difference” value to the current value of the Offset Field.

Additionally, the value recorded by OriginalBytecodeSize is added to the current value of the Offset Field (incorporating the “difference value”). Again, the reason for this is explained in more detail below.

Processing then returns to step1840.

Again, the value of variable CMF is analyzed, at step1970, to determine whether the reference is to a field. If CMF does reference a field, processing continues to step1980. Otherwise, an error is raised and appropriate error-handling procedures invoked at step1990.

Step1980compares the value of variable CMF, i.e., the name of the field, against the names of fields already included in the UpgradeFieldList. If the comparison determines that the field name, as recorded by variable CMF, has been included in the UpgradeFieldList, processing continues to step2000. If the comparison determines that the field name, as recorded by variable CMF, has not been included in the UpgradeFieldList, an error is raised and appropriate error-handling procedures invoked at step2010.

At step2000, the reference to the field name is replaced with the index value of the corresponding method name in UpgradeMethodList. Thereafter, at step2020, the Offset Field value for the method name is analysed. If the Offset Field value is set to its initialised value (such as a null value), processing returns to step1840where the linear scan resumes and the next class, method or field reference is processed.

If the Offset Field value is set to any value other than its initialised value, the Offset Field value is corrected at step2030. This correction is achieved by determining the then current size, in memory address terms, of the upgrade bytecode74and subtracting from that value the value recorded by UpgradeBytecodeSize. This results in a “difference” value that is the result of previous replacements. The Offset Field value then being processed is then “corrected” by adding this “difference” value to the current value of the Offset Field.

Additionally, the value recorded by OriginalBytecodeSize is added to the current value of the Offset Field (incorporating the “difference value”).

Processing then returns to step1840.

Phase7,2040, commences with step2050(seeFIG. 18). Step2050inserts the UpgradeClassList, the UpgradeMethodList and the UpgradeFieldList, as well as the local constant data arrays, in to virtual table92. Virtual table92, comprises a series of records. In addition to fields for storing canonical class lists, canonical method lists, canonical field lists and local constant data arrays, each record contains a unique identifier. In the embodiment presently being described, the unique identifier for each record is the size of the concentrated original bytecode, ie. the value of OriginalBytecodeSize. Records within the virtual table92are sorted, in ascending order, according to the value of the unique identifier.

Processing then continues to step2060where the UpgradeClassList of the newly inserted record is reset to its initial entry, ie. the entry pointed to by ClassListStart. The first class, ie. the class pointed to by ClassListStart, is then assigned, at step2070, to a variable UC and the class recorded by variable UC will be referred to as “Class UC”. In successive iterations of step2070, variable UC is assigned the name of the next class in the UpgradeClassList of the newly inserted record. Upon reaching the end of the UpgradeClassList, i.e., the class pointed to by ClassListEnd has previously been processed, variable UC is assigned an “end-of-list” value (i.e., a null value).

At step2080, Class UC is analysed. If Class UC has been assigned a null value, processing continues to step2130. Otherwise, processing continues to step2090.

At step2090, Class UC is compared against the classes contained in the OriginalClassList (more particularly, the canonical class list of the record stored in the virtual table92that corresponds with the OriginalClassList). If a corresponding entry to Class UC is found in the OriginalClassList, processing continues to step2100. Otherwise processing returns to step2070where the next class in the UpgradeClassList is processed.

The Offset Field value of Class UC is analysed, at step2100, to determine whether this value is set to its initialised value. If so, the Offset Field value of Class UC is set, at step2110, to equal the Offset Field value of the class corresponding to Class UC in the OriginalClassList. If the Offset Field value of Class UC is set to a value other than its initialised value, then, at step2120, the Offset Field value of the class corresponding to Class UC in the OriginalClassList is set to equal the Offset Field value of Class UC.

The former arrangement thus allows the UpgradeClassList to correctly reference classes defined in the OriginalClassList, while the latter arrangement allows for dynamic upgrading of existing classes by pointing the original entry to the start of the bytecode that forms the upgraded class.

Processing then returns to step2070where the next class in the UpgradeClassList is processed.

At step2130the UpgradeMethodList of the newly inserted record is reset to its initial entry, i.e., the entry pointed to by MethodListStart. The first method, ie. the method pointed to by MethodListStart, is then assigned, at step2140, to a variable UM and the method recorded by variable UM will be referred to as “Method UC”.

In successive iterations of step2140, variable UM is assigned the name of the next method in the UpgradeMethodList of the newly inserted record. Upon reaching the end of the UpgradeMethodList, i.e., the method pointed to by MethodListEnd has previously been processed, variable UM is assigned an “end-of-list” value (i.e., a null value).

At step2150, Method UM is analysed. If Method UM has been assigned a null value, processing continues to step2200. Otherwise, processing continues to step2160.

At step2160, Method UM is compared against the methods contained in the OriginalMethodList (more particularly, the canonical method list of the record stored in the virtual table92that corresponds with the OriginalMethodList). If a corresponding entry to Method UM is found in the OriginalMethodList, processing continues to step2170. Otherwise processing returns to step2140where the next method in the UpgradeMethodList is processed.

The Offset Field value of Method UM is analysed, at step2170, to determine whether this value is set to its initialised value. If so, the Offset Field value of Method UM is set, at step2180, to equal the Offset Field value of the method corresponding to Method UM in the OriginalMethodList. If the Offset Field value of Method UM is set to a value other than its initialised value, then, at step2190, the Offset Field value of the method corresponding to Method UM in the OriginalMethodList is set to equal the Offset Field value of Method UM.

The former arrangement thus allows the UpgradeMethodList to correctly reference methods defined in the OriginalMethodList, while the latter arrangement allows for dynamic upgrading of existing methods by pointing the original entry to the start of the bytecode that forms the upgraded method.

Processing then returns to step2140where the next method in the UpgradeMethodList is processed.

Step2200sees the UpgradeFieldList of the newly inserted record reset to its initial entry, i.e., the entry pointed to by FieldListStart. The first field, i.e., the field pointed to by FieldListStart, is then assigned, at step2210, to a variable UF and the field recorded by variable UF will be referred to as “Field UF”.

In successive iterations of step2210, variable UF is assigned the name of the next field in the UpgradeFieldList of the newly inserted record. Upon reaching the end of the UpgradeFieldList, i.e., the field pointed to by FieldListEnd has previously been processed, variable UF is assigned an “end-of-list” value (i.e., a null value).

At step2220, Field UF is analysed. If Field UF has been assigned a null value, processing continues to step2270. Otherwise, processing continues to step2230.

At step2230, Field UF is compared against the fields contained in the OriginalFieldList (more particularly, the canonical field list of the record stored in the virtual table92that corresponds with the OriginalFieldList). If a corresponding entry to Field UF is found in the OriginalFieldList, processing continues to step2240. Otherwise processing returns to step2210where the next field in the UpgradeFieldList is processed.

The Offset Field value of Field UF is analysed, at step2240, to determine whether this value is set to its initialised value. If so, the Offset Field value of Field UF is set, at step2250, to equal the Offset Field value of the field corresponding to Field UF in the OriginalFieldList. If the Offset Field value of Field UF is set to a value other than its initialised value, then, at step2260, the Offset Field value of the field corresponding to Field UF in the OriginalFieldList is set to equal the Offset Field value of Field UF.

The former arrangement then allows the UpgradeFieldList to correctly reference fields defined in the OriginalFieldList, while the latter arrangement allows for dynamic upgrading of existing fields by pointing the original entry to the start of the bytecode that references the upgraded field.

Processing then returns to step2210where the next class in the UpgradeClassList is processed.

At step2270, the upgrade bytecode74is appended to the original bytecode72to form an integrated bytecode76. Once integrated, the upgrade process is completed, as illustrated at step2280.

It should be noted that steps2040to2260is performed at the site of the virtual table, which may be the location of the data processing system40containing the original bytecode or some other remote system. Furthermore, in alternative embodiments, the actions that form step2050can be delayed and performed in conjunction with step2270.

Execution of the integrated bytecode76will now be described with reference toFIGS. 19 and 20.

At step2290, the memory address of the first instruction in the integrated bytecode is assigned to variable MemoryAddressStart. Thereafter, at step2300, the first record in the virtual table is designated the “operative” record. The canonical list of classes, methods and fields of the operative record form the “ClassList”, “MethodList” and “FieldList” referred to below. Similarly, the local constant data arrays associated with the canonical list of classes of the operative record forms the local constant data array.

Processing then continues as follows.

Each instruction in the integrated bytecode76consists of an opcode specifying the operation to be performed, followed by zero or more operands supplying arguments or data to be used by the operation. As shown inFIG. 19, the first step in the execution of an instruction is to fetch the opcode, step2310. At step2320, it is determined whether the opcode fetched has any operands associated with it. If not, operation branches forward to step2330in which the operation specified by the opcode is executed.

If there are operands, operation proceeds to step2340in which the operands are fetched from the bytecode. Operation then proceeds to step2350in which it is determined whether any of the fetched operands needs to be resolved. Generally, an operand will need to be resolved if it is not a literal constant. Opcodes that refer to classes, methods of fields have operands that need to be resolved. The type of operand is implied by the opcode. For example, the “putfield” operation take a value of the stack and moves it into the field of an object. The operand which immediately follows the “putfield” operator in the bytecode is a field identifier which specifies the field. In bytecode concentrated in accordance with the present invention, the operand will be an index into the FieldList.

If no operand needs to be resolved, operation proceeds to step2330in which the operation specified by the opcode is executed using the operands. If there are operands to be resolved, operation proceeds to step2360in which the operands are resolved. This procedure will be described in greater detail below with reference toFIG. 20. Once the operands have been resolved, operation continues to step2330in which the operation specified by the opcode is carried out with the resolved operands. Thereafter, at step2370, the next opcode to be processed is determined with reference to the Offset Field values of the operands.

Once the current instruction is executed, it is determined in step2380whether there are more instructions in the integrated bytecode76to be executed. If there are, operation loops back to step2310in which the next opcode to be executed is fetched. If there are no more instructions to be executed, operation terminates at step2390.

FIG. 20illustrates an exemplary procedure for resolving operands in accordance with the present invention. In step2400, the memory address of the opcode, to which the operand then being processed relates, is assigned to a variable CurrentMemoryAddress.

The value of CurrentMemoryAddress is then adjusted by subtracting the value of MemoryAddressStart to determine the relative offset value of the opcode.

The value of CurrentMemoryAddress is then analysed at step2410. If the value of CurrentMemoryAddress is greater than the value of the unique identifier for any record in the virtual table92, other than the unique identifier for the current operative record, processing continues to step2420. Otherwise, processing continues at step2430.

At step2420, a new record is designated as the operative record. The new operative record is the record having a unique identifier value closest to, but not exceeding, the value of CurrentMemoryAddress. Once identified, the ClassList, MethodList and FieldList are changed to reflect those recorded in the new operative record. Processing then continues to step2430.

Step2430sees the operand to be resolved assigned to a variable N. In step2440, it is determined whether the operand is a class. As discussed above, the type of operand is implied from the opcode. If the operand N is a class, operation proceeds to step2450in which the operand itself is used as an index into the ClassList.

At step2450, and using the operand as an index to the ClassList, a string is retrieved from the ClassList which is the identifier of the class which is the operand. The retrieved string replaces the index, and operation either proceeds to step2330if all operands that need to be resolved have been resolved, or to step2430if there are more operands to be resolved.

If at step2440it is determined that the operand N is not a class, operation proceeds to step2460in which it is determined whether the operand to be resolved is a field. If it is determined that the operand N is a field, operation proceeds to step2470in which the operand itself is used as an index into the FieldList.

At step2470, and using the operand as an index to the FieldList, a string is retrieved from the FieldList which is the identifier of the field which is the operand. The retrieved string replaces the index, and operation either proceeds to step2330is all operands that need to be resolved have been resolved, or to step2430if there are more operands to be resolved.

If at step2460it is determined that the operand N is not a field, operation proceeds to step2480in which it is determined whether the operand to be resolved is a method. If it is determined that the operand N is a method, operation proceeds to step2490in which the operand itself is used as an index into the MethodList.

At step2490, and using the operand as an index to the MethodList, a string is retrieved from the MethodList which is the identifier of the method which is the operand.

The retrieved string replaces the index, and operation either proceeds to step2330is all operands that need to be resolved have been resolved, or to step2430if there are more operands to be resolved.

If at step2480it is determined that the operand is not a method, an error is raised and appropriate error-handling procedures invoked at step2500.

It is possible to use the invention described herein for multiple upgrades of the original bytecode72. When doing so the integrated bytecode76formed from previous upgrades constitutes the original bytecode72. The unique identifier for each record created by such upgrade is then allocated a value equal to the total size, in memory address terms, of the original bytecode72and the subsequent appended upgrade bytecode(s)74.

One skilled in the art will appreciate that the present invention can be practiced by other than the preferred embodiments which are presented herein for purposes of illustration and not of limitation.