Suche Bilder Maps Play YouTube News Gmail Drive Mehr »
Erweiterte Patentsuche | Abbildungen der Seite | Webprotokoll | Anmelden

Patente

  
[merged small][graphic][merged small][merged small][merged small][merged small][merged small][graphic][merged small][merged small][merged small]
[merged small][merged small][graphic][graphic][merged small][merged small][merged small][merged small][merged small][merged small][graphic][merged small][merged small][merged small][merged small][merged small][graphic][merged small][merged small][merged small][merged small][merged small][merged small][graphic][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small][merged small]

l

SYSTEM AND METHOD FOR RESOLVING

SYMBOLIC REFERENCES TO
EXTERNALLY LOCATED PROGRAM FILES

The present invention relates generally to object oriented distributed computer systems, and particularly to a program execution system and method in which a source program may reference, via symbols, methods (i.e., programs) stored at remote locations.

BACKGROUND OF THE INVENTION

An interpreter is a computer program that translates and executes instructions written in a programming language, such as programs written in the Java bytecode language. Hie translation process involves the conversion of each source language statement of a given computer program into machine language suitable for execution. A user wishing to execute an application program written in the programming language will invoke an interpreter in order to execute the application program.

In object oriented programming languages, every object belongs to a specific "class," sometimes called an object class. Every object is an instance of a respective object class. Further, programs in object oriented computer systems are often called "methods," and each method belongs to a respective object class.

Methods (particularly application programs) often contain references to other methods that are located separate and apart from the calling method. Typically, these references take the form of a unique name or symbol which corresponds to the particular sub unit of code. As part of the interpretation process required to execute a given method, the interpreter must resolve each reference or symbol in order to locate and ultimately translate the method associated with a given symbol.

In the prior art. the interpretation process for a symbolic reference to a method involved a one or two step process. Some prior art interpreters utilize local system resources (libraries and the like) to resolve symbolic references. In the event the local system resources could not resolve a given symbol, then the interpretation (compilation) aborts with an appropriate message to the user. In other prior art interpreters, if the local resources could not resolve a symbolic reference, then a search strategy is invoked. The particular search strategy invoked by the interpreter may be unique to the individual computer. Accordingly, the ability of the interpreter to resolve these unknown (at least locally) symbolic references is directly related to the effectiveness of the resident search routine. Again, as with other prior art interpreters, if the symbol could not be resolved by the resident search routine, then the interpretation process aborts with an appropriate message to the user.

In a distributed computer system, a method being executed by a first (client) computer may contain references, herein called symbols, to methods located on a number of other (server) computers. In order to translate and execute a method which contains references to remotely stored methods, the program interpreter is required to resolve all of the references to remote methods. However, the local system resources (client resources) available to an interpreter to translate symbolic references may not be the same as the resources (server resources) available at the other server computers. Specifically, the resources available at a server computer may be more expansive or the server may employ a different search routine which has been tailored to the object classes stored at its location.

2

Furthermore, when a first method is loaded from a remote server, any additional methods called by the first method are likely to be located on the same remote server that supplied the first method. Importantly, the remote server may store a

5 version of the called method that is required for correct operation of the first method. In other words, there may be many methods having the same name that are located on various client and server computers. Thus, when Method A on Server 1 makes a call to Method X. and different versions of Method A are stored on various servers and clients. Method X on Server 1 most likely needs to use the Server 1 version of Method X. Therefore, in most circumstances, the first place to look for such called methods would be that same remote server. However, if the client's default class loading procedure is

15 used to locate and load these called methods, local resources will be searched first, and the search for the called methods either may never be extended to the remote server, or may extend to the remote server only after an unfruitful search of the local resources. This is wasteful, and may result in the

20 wrong method (i.e., the local version of the called method instead of the remotely stored version) being loaded.

It is therefore an object of the present invention to provide a method and system for resolving symbolic references to remotely located methods. It is an associated object of the

25 present invention to provide a method and system in which the default search strategy for locating a called method is superseded by an application specific search strategy when the calling method was loaded by the executing client

3o computer from a remotely located server.

SUMMARY OF THE INVENTION

In summary, the present invention is a program interpreter, and method, for interpreting object oriented programs in a computer system having a memory that stores

35 a plurality of objects and a plurality of methods. In a preferred embodiment, the program interpreter resolves references to remotely located methods called while interpreting a first method. When the program interpreter on the client computer encounters a reference to a second, remotely

*> stored method, the client computer creates an application specific class loader which contains location information indicating the server computer on which the referenced method is stored. The application specific class loader is then used to load the object class associated with the second

45 method from the server computer location indicated in the application specific class loader. The application specific class loader is also utilized to resolve all method calls, in the form of symbolic references, within the second method. A separate application specific class loader is created for

50 each reference encountered while interpreting a locally stored first method to methods stored on remotely located servers, unless the object class for the referenced method has already been loaded (e.g., in response to a previously encountered method call for the same or a different method

55 in the same object class). The application specific class loaders are created by a bootstrap class loader that also handles the loading of locally stored object classes. The application specific class loaders handle the loading of remotely located object classes. The methods of each appli

60 cation specific class loader may incorporate load policies associated with the respective server location, which differ from the load policies used by the client computer's bootstrap class loader.

65 BRIEF DESCRIPTION OF THE DRAWINGS

Additional objects and features of the invention will be more readily apparent from the following detailed descrip

3 4

tion and appended claims when taken in conjunction with object of the appropriate object class be generated. The class

the drawings, in which: loader 116 loads in the appropriate object class and calls the

FIGS. 1A and IB are block diagrams of a distributed bytecode program verifier 112 to verify the integrity of all

computer system incorporating the present invention. the bytecode programs in the loaded object class. If all the

Uiij- fu**. i Ij 5 methods are successfully verified an object instance of the

FIG. 2 is a block diagram of a bootstrap class loader object class is generated; and the bytecode intexpreter 114 is

according to one embodiment of the present invention. in£ked tQ exe*ute the usef reques£d memod ^ ...

PIG. 3 is a block diagram of an application specific class requested by the user is not a bytecode program and if

loader according to one embodiment of the present inven- execution of the non-bytecode program is allowed (which is

tion. outside the scope of the present document), the program is

FIG. 4 is a block diagram of an object loaded by the executed by a compiled program executer (not shown),

application specific class loader of FIG. 3. The bootstrap class loader 116 is also invoked whenever

FIG. 5 is a flow chart of a method for loading the object a°. executing bytecode program encounters a call to an

class associated with an application program from a server meth^ for an <J»ect A* haS y5 ^

computer according to the present invention. 15 \oa**TM*. address .sfceK.°fe agam the class

, » . r - loader 116 loads in me appropriate object class and calls the

FIG. 6 is a flow chart of a method for translating an bytecode program verifier 112 to verify the integrity of all

unresolved symbolic reference by an interpreter according to the bytecode programs in the loaded object class. If all the

the present invention. methods in the loaded object class are successfully verified,

npsrRnmrw Hf Top Pptjfbprpti an ob->ect instance of the object class is generated, and the

DESCRIPTION OF TOE PREFERRED 20 b tecode interpreter U4 is invoked to execute the called

EMBODIMENTS object method.

Referring to FIG. 1, there is shown a distributed computer As will be explained in more detail below, the bootstrap

system 100 having many client computers 102 and at least class loader 116 is not used in the present invention to load

one remotely located information server computer 104. In object classes from remotely located computers, such as one

the preferred embodiment, each client computer 102 is 25 °f the sewers 104 shown in FIG. 1. Rather, an application

connected to the information servers 104 via the Internet specific class loader is generated by the bootstrap class

103. although other types of communication connections loader, and then that application specific class loader is used

could be used. While most client computers are desktop t0 load me remotely located object class,

computers, such as Sun workstations. IBM compatible com- The term "method" is used in this document synony

puters and Macintosh computers, virtually any type of 30 mously with the terms "program" and "application program"

computer can be a client computer. In the preferred to refer to a program that is in an object class,

embodiment, each client computer includes a CPU 105. a As shown "» mGS- 1A and 1B< *e bytecode program

communications interface 106. a user interface 107. and interpreter 114 includes a work array 130 in which a working

memory 108 Memory 108 stores- representation of all currently loaded and executing methods

an operating system 109;' 35 are temporarily stored.

T . The information server 104 includes a central processing

an Internet communications manager program 110: ,,- ,. , .

"5 1 *~ » unit ISO. primary memory 152 (i.e.. fast random access

a bytecode program verifier 112 for verifying whether or memory) and secondary memory 154 (typically disk

not a specified program satisfies certain predefined storage), a user interface 156. a communications interface

integrity criteria; ^ jgg for communication with the client computers 102 via

a bytecode program interpreter 114 for executing byte- the communications network 106. For the purposes of the

code programs (i.e„ methods); present discussion, it will be assumed that the information

a bootstrap class loader 116, which loads object classes server's secondary memory 154 stores:

into a user's address space and utilizes the bytecode an operating system 160, and

program verifier to verify the integrity of the methods 45 program source files 162,164, 166, 168.

associated with each loaded object class; A second server computer 104 includes the same basic

at least one class repository 120, for locally storing object elements (not shown) and a memory for storing a program

classes 122 in use and/or available for use by user's of 170.

the computer 102; As is often the case, a user operating a browser such as

at least one object repository 124 for storing objects 126, 50 HoUava on the Internet may desire to load from a remote

which are instances of objects of the object classes location on the Internet an application program for execution

stored in the object repository 120. locally on the user's client computer. In order to do so, the

In the preferred embodiment the operating system 109 is user will invoke the class loader associated with the browser

a object oriented multitasking operating system that supports application, often referred to as the bootstrap class loader

multiple threads of execution within each defined address 55 116. The bootstrap class loader 116 creates a local copy of

space. Furthermore, in the preferred embodiment the byte- the object class associated with the user selected application

code program verifier 112 and interpreter 114 are a Java program and prepares the method or methods in that object

bytecode program verifier and interpreter for working with class for local execution.

Java bytecode programs. Java is a platform independent Referring now to FIG. 2, a bootstrap class loader 116

language and technology marketed by Sun Microsystems, 60 according to one embodiment of the present invention is

Inc. In addition, the Internet access procedure 110 in the shown. The bootstrap class loader 116 includes both a class

preferred embodiment is the Hot Java browser, and is reference 202 that points to a set of methods in the assori

embodied as a method in an associated object class that is ated object class, and a data reference 204 that points to a

stored in a local class repository 120 in the client computer's data array 205. The methods in the bootstrap class loader

memory 108. 65 object class include a fetch method 206. a linking method

The bootstrap class loader 116 is typically invoked when 208. a load method 210. and an application specific class

a user first initiates execution of a memod, requiring that an loader generator method 212.

5

The fetch method 206 includes the methods required to fetch (i.e., locate and copy) a locally stored object class, as well as to determine if the object class containing a referenced method is stored at a remote location. Linking method 208 includes a method for linking the methods in the fetched 5 object class to the bootstrap class loader by modifying the code of those methods to include a constant or variable (e.g., a variable named ClassLoader) whose value identifies the class loader used to load the fetched object class. The load method 210 includes a method for loading the fetched and 10 linked object class into the program interpreter. The application specific class loader generator method 212 includes a method for generating application specific class loaders.

The data array 205 includes a symbol table 214 associated with the bootstrap class loader 116. The symbol table 214 15 includes a list of symbols previously resolved by the class loader as well as data indicating the exact location of the code associated with the symbolic references.

Referring now to FIG. 3. an application specific class loader 300 as created by the application specific class loader 20 generator method 212 of the present invention is shown. The generator method 212 creates an application specific class loader 300 which will be linked to an application program (i.e., method) in an object class that has been loaded from a remote server. The application specific class loader 300 itself 25 contains both a class reference 302 and a data reference 304 to a data array 305. The class reference points to a set of methods that include: 1) location information 303 for a remotely located server computer, typically a server computer; 2) a fetch method 306 for fetching object classes from 30 a remote server computer to a client computer; 3) a linking method 308; 4) a load method 310. and, in some embodiments, 4) an application specific class loader generator method 312. The location information 303 identifies the particular server computer on which an object class 35 referenced by a locally stored method is stored. The location information 303 is preferably embedded in the fetch method 306.

In one embodiment, fetch method 306 is the same fetch method 206 found in the bootstrap class loader 116. except 40 that it includes (he location information 303 needed to locate the server from which additional object classes are to be loaded. In an alternative embodiment, the fetch method 306 is customized to the server computer and includes policy checks implemented by the server computer. In this alter- 45 native embodiment, the fetch method 306 incorporates policy considerations, including limitations proscribed by either the source or the destination of the object class to be relocated. For example, limitations on the set of resources to be searched (e.g., which object class repositories, and which 50 other servers, if any) to locate a called method may be incorporated into the fetch method 306. For instance, the fetch method in all application specific class loaders can be coded to invoke a search strategy procedure having a predefined name, such as "SearchPolicyProc," that if present 55 on a server invokes the object class fetch policies of that server computer. If the SearchPolicyProc is not present on the server, the version of that procedure on the client computer is used.

In the preferred embodiment, the linking method method 60 308 is the same as the linking method method 208 as described in association with the bootstrap class loader 116. The load method 310 is also the same as the load method 210 as described in association with the bootstrap class loader 116. In the preferred embodiment, application specific class 65 loaders do not include an application specific class loader generator method 312, because it is assumed that all symbol

6

references to be resolved by the application specific class loader will be successfully resolved by locating an associated object class on either the server identified by the location information 303. on any other server computers referenced by the search policy of the identified server computer, or on the client computer.

As indicated above, it is possible that the application specific class loader 300 will search for the object class corresponding to a called method not only on the server specified by the location information, but on other servers as well. In an alternate embodiment, when the object class for the called method is located on a different server than the one identified by the location information 303, a new application specific class loader is generated for that called method by the generator method 312. The new application specific class loader is then used to load the object class on that other server as well as to locate and load the object classes for any method calls made by that method. In this way, the application specific class loader 300 is capable of constructing other application specific class loaders.

The data array 305 for the application specific class loader includes a symbol table 314. The symbol table 314 includes a list of resolved symbols as well as data indicating the exact location of the code associated with the symbolic references.

FIG. 4 shows the data structure for an object 400 that is an instance of an object class loaded by an application specific class loader. The object 400 includes a class reference pointer 402 to an array of methods and a data reference pointer 404 to a data array 405. The methods in the methods array include at least one method 406, and each of those methods includes code 407 (i.e. a program instruction) defining a constant or variable whose value identifies the class loader used to load the associated object class. Program code 407 is sometimes referred to as the class loader ID. The class loader identified by the class loader ID 407 is the bootstrap class loader if the object class was loaded by the bootstrap class loader, and is otherwise the application specific class loader that was used to load the object class.

As explained above, the linking method 208.308 modifies each of the methods in an object class during the loading process so as to insert the declaration of the associated class loader ID 407.

Data array 405 stores any data and pointers that may be necessary to execute the underlying methods of the object 400.

Referring now to FIG. 5, a flow chart associated with the loading of an application program from a remote server computer according to the present invention is shown. Auser operating a browser, such as Hot Java, identifies an application program (i.e., method) for downloading to local memory in his or her respective client computer (500). Alternately, execution of a method previously launched encounters a reference to a method whose object class is stored on a remote server computer. The browser initiates the loading of the object class associated with the identified method into local memory by invoking the bootstrap class loader (502).

Assuming that the object class for the identified method has not already been loaded into the client computer, the bootstrap class loader creates an application specific class loader for the identified method (504). The application specific class loader includes embedded location information for identifying the server computer on which the identified application program is stored. In addition, the application specific class loader includes a method, or instructions, for loading object classes from the server computer to the client computer on which the application

« ZurückWeiter »