US 6,163,880 AGrant

Object Model for Java.TM.

Issue Date:2000-12-19

•36 Claims

•9 Drawing Sheets

Abstract

The mechanism includes three data structures: object data associated with each object O1, O2, O3 ... of a program, a class descriptor associated with the classes to which the objects O1, O2, O3 ... belong, and interface references. For each class C.sub.i, the class descriptor corresponding to the class C.sub.i includes: i) a class method table comprising one or more entries, wherein each entry identifies an implementation of a method inherited or defined by the class C.sub.i ; and ii) for each interface implemented by the class C.sub.i, an interface method table comprising one or more entries, wherein each entry identifies an implementation of a method declared by the particular interface or an implementation of a method declared by an interface extended by the particular interface. An interface reference for an interface declaration ID associated with a given object OI, wherein the object OI implements methods that are declared by an interface declaration ID includes a pointer to the interface method table corresponding to the interface declaration ID within the class descriptor corresponding to the object OI. An efficient mechanism for method invocations is provided by generating an index that identifies the entry corresponding to the appropriate method in the interface method table pointed to by the pointer of the interface reference, reading the data stored by the entry identified by the index, and controlling the computer processing apparatus to jump to the address identified by the data.

Metadata

Assignee

International Business Machines Corporation

Inventors

Ganesan Ramalingam
Harini Srinivasan

Application Information

Application Number:US 2596547

Filing Date:1999-02-26

Priority Date:1997-01-14

Art Unit:272

Classifications

IPC:

G06F 945

Field of Search:

395717701;702;7121;7

Patent Drawings (9 sheets)

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention generally relates to object oriented programming (OOP) systems and, more particularly, to OOP systems supporting the Java.TM. programming language.

2. Background Description

In current implementations of Java.TM., method invocations may involve a search through a method table to identify the (address of the) function to be invoked. A cache may be used to eliminate the search under certain circumstances. In contrast, a method invocation (typically referred to as a virtual function call) in C++ usually requires only a constant overhead: the address of the function to be invoked is obtained by simply indexing into a virtual function table, where the index value itself is a compile time constant. Thus, method invocations in current implementations of Java.TM. can be considerably more expensive than method invocations in C++. The present invention is directed at improving the performance of method invocation in OOP systems such as Java.TM..

In order to better understand the invention, some background material is presented regarding inheritance in the Java.TM. programming language, casts and method invocations in the Java.TM. programming language, and the implications of inheritance and method invocations on the object model utilized by current implementations of the Java.TM. programming language.

Inheritance in Java.TM.

Before understanding the Java.TM. inheritance mechanism, one must first understand the concepts of class and interface in Java.TM.. Java.TM. classes are more or less like classes in other languages, eg. C++, consisting of data members (variables) and member functions (methods). Inheritance is a mechanism that allows descendants of a class to inherit all (or portions) of the variables and methods from the ancestors of the class. Java.TM. allows only single inheritance among classes. The following pseudo-code illustrates the concept of single inheritance among classes:

Class C2 inherits from class C1. An object of type C2 will contain, in addition to its data `c2data`, the data members corresponding to those declared in C1 as well, i.e. `c1data`. C2 also inherits any methods implemented by C1 that it does not implement, i.e., f1.oval-hollow.. Likewise, C3 extends C2 and hence contains, in addition to `c3data`, both `c1data` and `c2data`. C3 also inherits implementation of method f2.oval-hollow., and has its own implementation of method f1.oval-hollow.. A more detailed description of Java.TM. classes and the single inheritance mechanism associated with Java.TM. classes may be found in "Java Language Specification", by James Gosling, Bill Joy and Guy Steele.

In addition the Java.TM. programming language provides for interfaces which specify the set of methods that must be implemented by any class that implements that interface (but does not provide any implementation of these methods itself. More specifically, the Java.TM. programming language provides for declarations wherein a user declares variables of type I, where I is an interface. Such variables can store a reference to an object of any class that implements the interface I. Such variables are referred to below as interface references. Interface references can be used to invoke any of the methods declared in the interface declaration. Importantly, the Java.TM. programming language provides for multiple inheritance among interfaces, i.e., an interface may extend multiple interfaces. Further, a class can implement multiple interfaces. For example, consider the following pseudo-code:

In this example, interface I introduces a method foo.oval-hollow.. Class C implements I and provides an implementation for foo.oval-hollow.. Class D defines both methods foo.oval-hollow. and zap.oval-hollow. introduced in interfaces I and J respectively. In this case, D implements multiple interfaces. The declaration of interface K illustrates multiple inheritance among interfaces since K extends both I and J. I, J, K introduce methods foo.oval-hollow., zap.oval-hollow. and zip.oval-hollow. respectively. Class E implements K and extends class C, and therefore, either defines or inherits implementations of foo.oval-hollow., zap.oval-hollow. and zip.oval-hollow.--it defines zap.oval-hollow. and zip.oval-hollow. and inherits C's implementation of foo.oval-hollow..

A more detailed description of interfaces and the multiple inheritance mechanism associated with interfaces may be found in "Java Language Specification", by James Gosling, Bill Joy and Guy Steele.

Method Invocations and Casts in Java.TM.

The use of interface references is illustrated in the pseudo-code above. In function main.oval-hollow., statement s1 declares pi to be an interface reference to interface I. Statement s2 creates an object of type C and assigns to pi a reference to this object. Statement s3 invokes foo.oval-hollow., the method declared in I and defined in C, via the interface reference pi that is pointing to the C object. The interface reference pi is used at run time to determine the exact implementation of foo.oval-hollow..

Casts in Java.TM. fall into two categories: static casts, whose validity can be established at compile time, and dynamic casts whose validity needs to be checked at run time. A cast from a type S to a type T is static if S is a subtype of T, and dynamic otherwise. More specifically, a cast from a derived class to a base class is a static cast and requires no run time test to determine the validity of the cast However, a cast from a class B to another class D, where class B does not derive from class D, is a dynamic cast and requires a ran time test to determine the validity of the cast.

Consider the following code, where D is a derived class of B:

s1: B bp;

s2: if (P) bp=new B; else bp=new D;

s3: D dp;

s4: dp=(D) bp;

At s1, bp is declared to be a class reference of type B. The `if statement in s2 assigns a value to bp: if the if-condition, P, is `true`, bp is assigned a reference to a B object, created by the `new B` statement; if P is `false`, bp is assigned a reference to a D object, created by the `new D` statement. Therefore, depending on the run-time value of P, bp either points to a B object or a D object at run-time. At s3, dp is declared to be a class D reference. The cast in line s4 assigns a reference to a B object to a reference to a D object. Since B does not derive from D, this cast requires a run time check to make sure that bp points to a D object rather than a B object. The compiler would generate code at s4 for such a run-time check.

To implement this run time check, it is necessary to have some run time type information associated with objects. This type information need not be stored in the object itself. It is usually stored in the class descriptor. A more detailed description of information stored for a given object is now descnbed with respect to the Java.TM. object model.

Inmplications of Inheritance and Casts on the Java.TM. Object Model

An object model answers the following questions: How are objects laid out in memory, how are references (including interface references) laid out in memory, what data structures are necessary to implement object oriented language features such as inheritance, dynamic dispatch, dynamic casts, etc., how these data structures are laid out in memory, and finally what code sequences are required to implement object oriented language features.

In current Java implementations, a class descriptor is associated with every class. The class descriptor contains run-time type information, for doing type checks at run-time and a method table for the class. The method table is essentially a table of entries for methods implemented by the class. In some Java implementations, the method table in a class's descriptor also contains entries for methods inherited by the class. Each entry in a method table contains the address of a method and an identifier that identifies the method uniquely. The offset of a method's entry in method tables for different classes may be different. When a method is invoked, via a class reference or interface reference, a search of the method table using the identifier for the method may be required to determine the address of the method implementation.

In some Java implementations, this search is optimized for under certain circumstances--when a sequence of instructions containing a method invocation is executed multiple times, the offset of the method being invoked in the method table can be cached and this cached value can be used to reduce the overhead of the search ("The Java Virtual Machine Specification", by Tim Lindholm and Frank Yellin; "Method and Apparatus for Resolving Data References in Generated Code", U.S. Pat. No. 5,367,685 in the name of James Gosling.). However, the search during method invocation can not always be completely eliminated whenever an interface is implemented by multiple classes. Invocations of methods declared in such interfaces will be frequent in Java programs that separate interface from implementations, such as client-server distributed applications. It is therefore important to improve the performance of Java method invocations.

SUMMARY OF THE INVENTION

The above-stated problems and related problems of the prior art are solved with the principles of the present invention, Object Model for Java.TM.. The mechanism of the present invention includes three data structures: object data associated with each object O1,O2,O3 . . . of a program, a class descriptor associated with the classes to which the objects O1,O2,O3 . . . belong, and interface references.

The object data associated with a given object O.sub.i, which belongs to a class C.sub.i of objects, includes:

i) a pointer to a class method table in the class descriptor corresponding to the class C.sub.i (a more detailed description of the class descriptor is set forth below); and

ii) data, such as variables, associated with the object O.sub.i.

For each class C.sub.i, the class descriptor corresponding to the class C.sub.i includes:

i) a class method table comprising one or more entries, wherein each entry identifies an implementation of a method inherited or defined by the class C.sub.i ; and

ii) for each interface implemented by the class C.sub.i, an interface method table comprising one or more entries, wherein each entry identifies an implementation of a method declared by the particular interface or an implementation of a method declared by an interface extended by the particular interface.

Finally, an interface reference for an interface declaration ID associated with a given object OI, wherein the object OI implements methods that are declared by an interface declaration ID, includes:

i) a first pointer to the interface method table corresponding to the interface declaration ID within the class descriptor corresponding to the object OI; and

ii) a second pointer that identifies the object OI.

An efficient mechanism for method invocations is provided by generating an index that identifies the entry corresponding to the appropriate method in the interface method table pointed to by the first pointer of the interface reference, reading the data stored by the entry identified by the index, and controlling the computer processing apparatus to jump to the address identified by the data.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, aspects and advantages will be better understood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which:

FIG. 1(A) is a block diagram showing a hardware configuration on which the subject invention may be implemented;

FIG. 1(B) is a block diagram of a compiler apparatus of the present invention;

FIG. 1(C) is a block diagram of a hybrid compiler-interpreter apparatus of the present invention;

FIGS. 2-4 are pictorial illustrations of the data structures of the present invention;

FIG. 5 is a pictorial representation of an interface table of the present invention;

FIG. 6 is a pictorial representation of an interface function table of the present invention; and

FIG. 7 is a flow chart illustrating operations of method invocation according to the present invention.

FIGS. 8(A) and (B) are pictorial representations of a class-interface cast table and interface-interface cast table of the present invention.

FIG. 9 is a pictorial illustration of a class hierarchy.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION

The entire disclosure of U.S. Pat. application Ser. No. 08/782,995 filed Jan. 14, 1997 is expressly incorporated by reference herein.

Referring now to the drawings, and more particularly to FIG. 1, there is shown a representative computer processing apparatus on which the subject invention may be implemented. The computer processing apparatus includes a central processing unit (CPU) 10 and an instruction cache and data cache, which may be combined into a single cache I01 as shown. The instruction cache stores instructions to be executed by the CPU 10. The data cache stores data to be used in the execution of such instructions. The CPU 10 includes a plurality of execution units. The execution units may include a branch processor 102, one or more integer units (FXU) 103, and one or more floating point units (FPU) 104 as shown. The branch processor 102 executes branch instructions issued from the instruction cache. The FXU 103 executes integer based instructions issued from the instruction cache. And the FPU 104 executes floating point instructions issued from the instruction cache. The computer processing apparatus may also include additional execution units (not shown), for example a multimedia execution unit, for executing varying sets of instructions issued from the instruction cache. The instructions and data caches communicate with the bus interface 105.

The CPU 10 is attached to a system bus 12 to which are attached a random access memory (RAM) 14, a read only memory (ROM) 16, an input/output (I/O) adapter 18, and a user interface adapter 22. Typically, the user interface adapter 22 has attached to it a keyboard 24, a mouse 26, and/or other user interface devices such as a touch screen device (not shown). Such touch screen device would optionally be installed on the display 38, here represented as a cathode ray tube (CRT) display but which may be a liquid crystal display (LCD) or other suitable display device. The display 38 is connected to the system bus 12 via a display adapter 36.

The computer system's operating system (and other utilities), application program code and data are stored in persistent memory and temporarily loaded into RAM 14 for execution by the CPU 10. The persistent memory is typically provided by a disk drive 20 coupled to the CPU via an I/O adapter 18. In addition, persistent memory may be provided by resources coupled to the CPU 10 via the system bus and a network adapter 19. In this case, portions of the computer system's operating system (or other utilities), portions of the application program code and data may be retrieved from network resources and loaded into RAM 14 for execution by the CPU 10.

It should be noted that the methods of the present invention may be utilized in the generation and execution of a compiled program. A compiled program is generated by a compiler that compiles a source program thereby generating executable code for a specific computer architecture. As shown in FIG. 1(B), a compiler 10 accepts as an input (I) 12 a high-level language program and operates on it to an end of generating an output (O) 14 comprising an output target language program. The output target language program is typically executable on a specific computer architecture. The compiler 10 typically includes a front end (FE) 18, a symbol information data structure(s) 20 for recording information about symbols in an input program, an intermediate language generator (ILG) 22, an optimizer (OPT) 24, and a back end (BE) 26.

The front end 18 typically converts the input program 12 to a (possibly) different internal form (IF) that may be conveyed to the intermediate language generator 22. As part of the preparation of the internal form, the front end 18 typically parses and performs semantic analysis on the source code. The front end may save information in, and possibly retrieve information from, the symbol information data structure(s) 20. These symbol information data structures, if they are used, may either be separate from or adjoined to the intermediate form.

The intermediate language generator 22 produces intermediate language instructions (IL) from the internal form of the program, possibly consulting the symbol table 20. The intermediate language form of the program may be conveyed to the back end 26 either directly or by way of the optimizer 24. If the intermediate language (IL) form of the program is conveyed to the optimizer 24, then the optimizer produces a functionally equivalent and preferably faster or smaller version of the program, typically again in the intermediate form. This version of the program may then be conveyed to the back end 26. To this end, the optimizer 24 may be in communication with the symbol table 20. Once an intermediate language form of the program is received by the back end 26, either directly or after optimization, the back end 26 generates executable code for a specific computer architecture that is functionally equivalent to the intermediate language form of the program. In addition, for object oriented programming languages, the back end 26 implements an object model and generates code that implements the object oriented features used by the source program. In addition, the back end 26 may optimize the generated code. The constitutions and functions of these elements are well known and will not be otherwise described here. For example, further description on the various intermediate language generators and other functionality of the compiler may be found in A. V. Aho et al., "Compilers Principles, Techniques and Tools, Addison-Wesley, 1986.

It should also be noted that the methods of the present invention may be utilized in the generation and execution of a compiled-interpreted program. A compiled-interpreted program is generated and executed by a hybrid compiler-interpreter as shown in FIG. 1(C). The compilation step is performed at compile time and the interpretation step is performed at execution time. In this case, the compiler compiles the source program thereby generating code in intermediate form (IL). At execution time, the interpreter may execute the intermediate code (IL) or translate the IL into a sequence of instructions for execution on a specific computer architecture. The compiler operates similarly to the compiler described above for compiled programs; however, the back end processing is omitted. The interpreter may include a main interpretation routine and a number of operation specific routines. The main interpretation routine receives the intermediate code generated by the compiler as an input, interprets the code, and invokes the appropriate operation specific routine based upon the interpretation. Preferably, one of the operation specific routines of the interpreter handles method invocations. The constitutions of these elements and functions are well known and will not otherwise be described here. For example, Java.TM. programs are typically generated and executed as a compiled-interpreted program.

As previously described, an interface declaration specifies the set of methods that must be implemented by any class of objects that implements a given interface (but does not provide any implementation of these methods itself). For example, consider the class hierarchy illustrated in FIG. 9. A first interface declaration I1 extends a second interface declaration I2 and thus inherits directly from the interface declaration I2. A third interface declaration I3 extends the first interface declaration I1 and extends a fourth interface declaration I4, and thus inherits directly from interface declarations I1 and I4. Such inheritance is typically referred to as multiple inheritance of interfaces. The Java.TM. programming language is an example of a language that supports multiple inheritance of interfaces. In this example, the interface declaration I3 indirectly extends the interface declaration I2. The term "extends" or "extension" as used below with respect to inheritance of interfaces refers both to direct and indirect extensions of interfaces.

According to the present invention, a mechanism is provided for efficient dynamic method invocations in object oriented programming languages (such as the Java.TM. programming language) that support multiple inheritance among interfaces and/or classes that implement multiple interfaces. The mechanism of the present invention includes three data structures: object data associated with each object O1,O2,O3 . . . of a program, a class descriptor associated with the classes to which the objects O1,O2,O3 . . . belong, and interface references.

More specifically, the object data associated with a given object O.sub.i, which belongs to a class C.sub.i of objects, includes:

i) a pointer to a class method table in the class descriptor corresponding to the class C.sub.i (a more detailed description of the class descriptor is set forth below); and

ii) data, such as variables, associated with the object O.sub.i.

For a compiled program, the code for constructing the object O.sub.i is generated by the back end 26 (or other element) when processing a "new" statement and other similar statements. The object O.sub.i is constructed during the execution of such code. For a compiled-interpreted program, the IL code for constructing the object O.sub.i is generated by the compiler when processing a "new" statement and other similar statements. The object O.sub.i is constructed during the execution of such code. The object data for each object O.sub.i is preferably stored in RAM 14 when the program is executing.

For each class C.sub.i, the class descriptor corresponding to the class C.sub.i includes:

i) a class method table comprising one or more entries, wherein each entry identifies an implementation of a method inherited or defined by the class C.sub.i ; and

ii) for each interface implemented by the objects of the class C.sub.i, an interface method table comprising one or more entries, wherein each entry identifies an implementation of a method declared by the particular interface or an implementation of a method declared by an interface extended by the particular interface.

The class and interface method tables may share entries and thus reduce the space required for the class descriptor. The class descriptor typically includes additional data associated with the class. Such additional data is not directly relevant to the present invention. An example of such additional data may be found in "The Java Virtual Machine Specification", by Tim Lindholm and Frank Yellin, Addison Wesley, September, 1996. The class descriptor corresponding to the class C.sub.i preferably is generated when the class C.sub.i is declared. For a compiled program, the class descriptor is preferably generated by the back end 26 when processing a class declaration and stored in persistent memory for subsequent use at execution time. For a compiled-interpreted programn, the class descriptor is preferably generated by the compiler and stored in persistent memory for subsequent use by the interpreter at execution time.

Finally, an interface reference for an interface declaration ID associated with a given object OI, wherein the object OI implements methods that are declared by an interface declaration ID, includes:

i) a first pointer to the interface method table corresponding to the interface declaration ID within the class descriptor corresponding to the object OI; and

ii) a second pointer that identifies the object OI.

For both compiled programs and compiled-interpreted programs, code for generating the interface reference is preferably generated by the compiler when processing a cast to an interface reference type. Such code is stored in persistent memory for subsequent use at execution time. For static casts, the code executed at execution time does not require any run time checks. However, for dynamic casts, the code executed at execution time does require one or more run time checks.

For example, consider the following statements described in pseudo-code presented above:

s1: I pi;

s2: pi=new C;

Statement s1 declares pi to be an interface reference to an interface I, and statement s2 creates an object OC of type C and assigns to pi a reference to the OC object. As shown in FIG. 2, the object OC includes a pointer mptr to the class method table in the class descriptor for the class C, and the variable d associated with the object OC. Class C implements the method foo.oval-hollow. declared in the interface I. In this case, the class method table for class C preferably includes a single entry for the method foo.oval-hollow.. In addition, the interface method table corresponding to interface I also consists of a single entry for the method foo.oval-hollow., and thus may share the entry with the class method table as shown in FIG. 2. Finally, the interface reference pi includes pointers p1 and p2, where p1 points to the interface method table corresponding to the interface I in the C class descriptor, and p2 points to the OC object as shown.

In another example, consider the class D set forth in following statements with reference to the pseudo-code presented above:

s1: I pi;

s2: pi=new D;

In this case, statement s1 declares pi to be an interface reference to an interface I, and statement s2 creates an object OD of type D and assigns to pi a reference to the OD object. As shown in FIG. 3, the object OD includes a pointer mptr to the class method table in the class descriptor for the class D, and the variables (none shown) associated with the object OD. The Class D implements the methods foo.oval-hollow. and zap.oval-hollow., which are declared in interfaces I and J, respectively. As shown, the class method table for class D includes an entry for method foo.oval-hollow., which is shared by the interface method table corresponding to interface I. In addition, the class method table for class D includes an entry for the method zap.oval-hollow., which is shared by the interface method table corresponding to interface J. Finally, the interface reference for the object OD includes pointers p1 and p2, where p1 points to the interface method table corresponding to the interface I and p2 points to the OD object data as shown.

In another example, consider the class E set forth in following statements with reference to the pseudo-code presented above:

s1: J pj;

s2: pj=new E;

In this case, statement s1 declares pj to be an interface reference to an interface J, and statement s2 creates an object OE of type E and assigns to pj a pointer to object OE. As shown in FIG. 4, the object OE includes a pointer mptr to the class method table in the class descriptor for the class E, and the variables (none shown) associated with the object OE. The Class E inherits class C's implementation of foo.oval-hollow. and implements zip.oval-hollow. and zap.oval-hollow.. The method foo.oval-hollow. is declared in interface I, the method zap.oval-hollow. is declared in interface J, and the method zip.oval-hollow. is declared in interface K. In this case, the class method table for the class E includes an entry for the method foo.oval-hollow. corresponding to the interface I, an entry for the method zap.oval-hollow. corresponding to the interface J, and an entry for the method zip.oval-hollow. corresponding to the interface K. In addition, the interface method table corresponding to the interface I includes an entry for the method foo.oval-hollow.; the interface method table corresponding to the interface J includes an entry for the method zap.oval-hollow.; and the interface method table corresponding to the interface K includes an entry for the methods foo.oval-hollow., zap.oval-hollow. and zip.oval-hollow.. Such entries of the interface method tables in the class descriptor for the class E may be shared with the entries of the class method table as shown in FIG. 4. Finally, the interface reference pj for the object OE includes pointers p1 and p2, where p1 points to the interface method table corresponding to the J interface, and where p2 points to the OE object as shown.

In addition, the present invention preferably utilizes interface cast tables to implement casts. More specifically, a class-interface cast table is provided for each class of objects. Preferably, the class-interface cast table is part of the class descriptor for a given class. The class-interface cast table stores entries associated with the interfaces implemented by a given class, wherein each entry identifies the offset from the start address of the class method table to the interface method table corresponding to the given interface. For example, consider the class E as shown in FIG. 5. In this scenario, the class-interface cast table stores an entry for the interface I indicating a zero offset, an entry for the interface J indicating a offset of X, and an entry for interface K indicating a zero offset as shown in FIG. 8(A). The class-interface cast table is preferably generated by the compiler and used by the compiler in generating code for casts. The class-interface cast table is also used at execution time to implement dynamic casts. A more detailed description of static and dynamic casts is set forth below.

In addition, for each class of objects, an interface-interface cast table is provided for each interface implemented by that class. Preferably, the interface-interface cast table is part of the class descriptor for a given class. The location of the interface-interface cast table is preferably stored in the corresponding interface method table. The interface-interface cast table corresponding to a given interface stores entries associated with the interfaces extended by a given interface. Each entry identifies the offset from the start address of the interface method table corresponding to the given interface to the interface method table corresponding to the interface that extends the given interface. Consider the example presented above with respect to FIG. 5 where Interface K extends interfaces I and J, respectively. In this case, the interface-interface cast table for interface I and the interface-interface cast table for interface J are empty because the interfaces I and J do not extend any interfaces. However, the interface-interface cast table for the interface K stores an entry for the interface I indicating a zero offset, and an entry for the interface J indicating an offset of X as shown in FIG. 8(B).

In addition, the present invention preferably utilizes function tables to provide a mechanism for referencing the entries of the method table of a given class. A function table is provided for each interface implemented by a class. For a particular interface, the function table stores entries associated with the method(s) of the particular interface, wherein each entry identifies the offset of the entry corresponding to the given method within the interface method table corresponding to the particular interface. For example, consider the class E shown in FIG. 6. In this scenario, a function table associated with the interface I stores an entry for the method foo.oval-hollow. indicating a zero offset. A function table associated with the interface J stores an entry for the method zap.oval-hollow. indicating a zero offset value. And, a function table associated with the interface K stores an entry for the method foo.oval-hollow. indicating a zero offset, an entry for the method zap.oval-hollow. indicating a offset of X, and an entry for the method zip .oval-hollow. indicating a offset Y. The function table is preferably generated and used by the compiler in generating code for method invocations. A more detailed description of method invocations in set forth below.

Generation of Interface References

As described above, the interface reference of the present invention is associated with an interface that declares one or more methods and an object that implements the methods of the interface, and includes the following two pointers:

i) a first pointer to the interface method table corresponding to the associated interface; and

ii) a second pointer that identifies the object.

An interface reference is generated whenever one of the following four types of casts occur:

Type 1: static cast--from a class reference to an interface implemented

by that class;

Type 2: static cast--from a derived interface to a base interface;

Type 3: dynamic cast--from a class reference to an interface reference not

implemented by that class; and

Type 4: dynamic cast--from a first interface reference to a second interface

reference which is extended by the first interface reference.

First, consider a type 1 cast as illustrated in the following segment of code, where Class C implements interface I:

s0: C pc;

s1: pc=new C;

s2: I pi;

s3: pi=pc; Statement s0 declares pc to be a reference to class C. Statement s1 creates an object OC of type C and assigns to pc a reference to this object. Statement s2 declares pi to be an interface reference to an interface I. Statement s3 is an implicit cast of a class reference into an interface reference. This assignment is preferably implemented as follows. As shown in FIG. 2, the class descriptor for the class C includes an interface method table corresponding to interface I, and the OC object includes a pointer mptr to class method table for the class C. In addition, an interface table stores the offset from start of the class method table to the interface method table corresponding to the interface I, which is similar to the interface method table shown in FIG. 5. In this scenario, the second pointer of the interface reference is assigned a value that points to the OC object and the first pointer of the interface reference is assigned a value that points to the interface method table corresponding to the interface I. The value of the first pointer is preferably constructed by adding the appropriate offset as stored in the interface table to the mptr value stored in the OC object. The compiler preferably retrieves the appropriate offset from the interface table at compile time and generates code for performing the addition operation at execution time. Such code is stored in persistent memory for subsequent use at execution time.

Next, consider a type 2 cast from a derived interface I2 to a base interface I1 as illustrated in the following piece of code:

s1: I1 pi1;

s2: I2 pi2;

s3: pi1=pi2;

Statement s1 declares pi1 to be an interface reference to an interface I1. Statement s2 declares pi2 to be an interface reference to an interface I2. Statement s3 casts the I2 reference to an I1 reference and assigns it to pi1. As described above, the pi2 reference has two pointers p1 and p2. The first pointer p1 points to the interface method table corresponding to I2 within the class descriptor for a class C that implements I2. The second pointer p2 points to an object of class C. When processing the statement s3, the compiler preferably generates code for assigning two pointers p1' and p2' to the interface reference variable pi1 as follows. The value of p2' is copied from the value of p2. The value of p1' is obtained by reading the appropriate entry in the interface-interface cast table corresponding to I2 and adding the value of such entry to p1. The appropriate entry is the entry corresponding to the interface I1, which is identified by an index generated at compile time. In the scenario that I2 does not extend any interface other than I1, the value of p2' may be obtained by copying the value of p2. The code generated by the compiler is stored in persistent memory for subsequent use at execution time.

Next, consider a type 3 dynamic cast from an object reference to an interface reference as illustrated in the following code segment:

s1: I pi;

s2: pa=new A;

s3: pi=(I) pa;

Statement s1 declares pi to be an interface reference to an interface I. Statement s2 creates an object OA of type A and assigns to pa a reference to this object. Statement s3 casts the object reference pa to the I reference pi. When processing the statement s3, the compiler preferably generates code for assigning two pointers p1 and p2 to the interface reference variable pi as follows. The pa object may (or may not) implement the interface I. Thus, the s3 statement requires a run-time check to determine if the pa object points to an object that does implement I. This can be done by searching at run time the class-interface cast table for the class corresponding to the object pa to determine if the table includes an entry that corresponds to the interface I. If the search is not successful, a run-time error message is generated. However, if the search is successful, the interface reference pi is assigned pointer values as follows. As described above, pi has two pointer p1 and p2 . The first pointer p1 is formed by retrieving the offset stored in the entry in the class-interface cast table for the interface I and adding such offset to the mptr for the pa object. The second pointer p2 is formed by copying pa. The code generated by the compiler is stored in persistent memory for subsequent use at execution time.

Finally, consider a type 4 dynamic cast from a first interface I1 to a second interface I2 which is not extended by the first interface I1 as illustrated in the following code segment: ##EQU1## Statement s1 declares pi1 to be an interface reference to an interface I1. Statement s2 creates an object OA of type A and generates an interface reference pi1 having two pointers p1 and p2. The first pointer p1 points to the interface method table for the interface I1 in the class A class descriptor. The second pointer p2 points to the object OA. Statement s3 declares pi2 to be an interface reference to an interface I2. The I2 interface may (or may not) extend the I1 interface. Thus, the s4 statement requires a run-time check to determine if the I2 interface extends the I1 interface. This can be done by searching at run time the class-interface cast table for the class corresponding to the object pointed to by the second pointer p2 of the reference pi1 (in this example, object OA) to determine if the table includes an entry that corresponds to the interface I1. If the search is not successful, a run-time error message is generated. However, if the search is successful, the interface reference pi2 is assigned pointer values as follows. The interface reference pi2 has two pointer p1' and p2'. The first pointer p1' is formed by retrieving the offset stored in the entry in the class-interface cast table for the class corresponding to the object pointed to by the second pointer p2 of the reference pi1 (in this example, object OA) for the interface I2, and adding such offset to the mptr for the pa object. The second pointer p2 is formed by copying p2 of the pi1 interface reference. The code generated by the compiler is stored in persistent memory for subsequent use at execution time.

Method Invocation on Interface References

Method invocation code is generated by a compiler when processing a method invocation statement. Such code is stored in persistent memory for subsequent use at execution time. Given the above description, method invocations on an interface reference can be implemented efficiently. For example, consider the method invocation pi.foo.oval-hollow. of the class "Example" as presented above. As shown in FIG. 7, when executing the method invocation pi.foo.oval-hollow., the following operations are performed.

First, in step 700, an index is generated that identifies the entry corresponding to foo.oval-hollow. in the interface method table pointed to by the first pointer p1 of the interface reference pi. The index is preferably generated by adding the offset corresponding to the method foo .oval-hollow. stored in the interface I Function Table to the value stored by the first pointer p1 of the interface reference pi. The offset is preferably determined at compile time and added to the value of the first pointer p1 at execution time.

Second, in step 702, the data stored by the appropriate entry is read. The location of the data is identified by the index as calculated in step 700. Finally, in step 704, the method foo.oval-hollow. is called by controlling the computer processing apparatus to jump to the address identified by the data read in step 702. The method call of step 704 may require passing the pointer of the object that implements foo.oval-hollow. (i.e., the "this" parameter). In this case, the second pointer p2 of the interface reference pi may be copied as the "this" parameter.

As presented above, interface references are represented by a pair of pointers. In an alternate embodiment of the present invention, interface references may be represented by a single object pointer under certain circumstances. Consider a class A that implements an interface I. Assume that the interface method table for I and class method table for A are shared in A's class descriptor such that their starting addresses are the same. This allows the implementation to use a pointer to an A object directly as a reference to an interface I (since the additional interface method table pointer is now unnecessary, as it is the same as the mptr stored in the object). Hence, in such cases, it is not necessary to use a two-pointer implementation for interface references.

In such an implementation, both the one-pointer and two-pointer implementation of interface references need to co-exist. This makes a difference primarily in how the "this" pointer is generated during a method call on an interface reference. In the one-pointer implementation, the interface reference itself is the "this" pointer. In the two-pointer implementation, the second pointer in the interface reference is the "this" pointer. A bit in the interface method table can indicate if the corresponding interface reference variable uses the one-pointer or the two-pointer implementation. For example, for class A above, the interface method table for I can have the bit set to indicate that any interface reference that uses this table is a one-pointer. This bit can be used at method call time to generate the "this" pointer appropriately.

In summary, the present invention provides for interface references that comprise of two pointers. The first pointer is a pointer to one or more entries that identify implementation of methods of the interface. The second pointer is a pointer to an object that implements the methods of the interface. The first pointer is used to invoke the appropriate methods at run time. The second pointer is used primarily to pass as the "this" parameter when invoking methods on the interface reference.

Claims

We claim:

1. An article of manufacture comprising a computer useable medium having computer readable program code means embodied therein for representing interface references in an object oriented language, wherein objects correspond to one or more classes, a class is capable of implementing one or more interfaces, an interface is associated with a set of methods, said object oriented language provides for inheritance of said interfaces whereby a first interface may extend one or more other interfaces, and an interface reference IRi is associated with an interface ID IRi and with an object OI corresponding to a class that implements the interface ID IRi, the computer readable program code means in said article of manufacture comprising computer readable program code means for causing a computer to effect: (a) for each class Ci of objects, storing in memory descriptor data corresponding to said class Ci, wherein said descriptor data includes: for each interface declaration IDi implemented by said class Ci, an interface method table containing one of an implementation of a method declared by said interface declaration IDi and an implementation of a method declared by an interface declaration extended by said interface declaration IDi; and (b) for each interface IRi, wherein interface reference IRi is associated with an interface declaration ID IRi and corresponds to a given object OI, storing in memory a first identifier that identifies an interface method table corresponding to the interface ID IRi within the descriptor data for the class corresponding to the object OI, and storing in memory a second identifier that identifies said object OI.

2. An article of manufacture as recited in claim 1, the computer readable program code means in said article of manufacture further comprising computer readable program code means for causing a computer to effect: for each interface reference IR.sub.i, storing in memory a second identifier that identifies said object OI.

3. An article of manufacture as recited in claim 1, wherein for each class C.sub.i of objects, said descriptor data corresponding to said class C.sub.i stored in memory includes a class method table comprising one or more entries, wherein each entry identifies an implementation of a method inherited or defined by said class C.sub.i.

4. An article of manufacture as recited in claim 1, the computer readable program code means in said article of manufacture further comprising computer readable program code means for causing a computer to effect: for each object O, storing in memory a third identifier for identifying a class method table within said descriptor data associated with a class corresponding to said object O.

5. An article of manufacture as recited in claim 1, wherein said descriptor data corresponding to said class C.sub.i is created and stored in memory when said class C.sub.i is declared.

6. An article of manufacture as recited in claim 1, the computer readable program code means in said article of manufacture further comprising computer readable program code means for causing a computer to effect: creating and storing in memory code for generating said first identifier corresponding to said interface reference IR.sub.i upon detection of a statement wherein said object OI is assigned to said interface reference IR.sub.i corresponding to said interface declaration ID.

7. An article of manufacture as recited in claim 1, the computer readable program code means in said article of manufacture further comprising computer readable program code means for causing a computer to effect: creating and storing in memory code for generating said first identifier corresponding to said interface IR.sub.i upon detection of a statement wherein an interface reference IR.sub.j is assigned to said interface reference IR.sub.i.

8. An article of manufacture as recited in claim 1, the computer readable program code means in said article of manufacture further comprising computer readable program code means, wherein when a method M is invoked via a reference to an interface declaration ID.sub.M, said computer readable program code means causes a computer to effect: (i) retrieving from memory said second identifier associated with the interface declaration ID.sub.M, wherein said second identifier identifies said interface method table corresponding to said interface declaration ID.sub.M ; (ii) generating an index corresponding to said method M based upon said second identifier retrieved from memory, wherein said index identifies an entry in said interface method table corresponding to said method M; (iii) retrieving said entry identified by said index; and (iv) invoking said method M using the retrieved entry.

9. An article of manufacture as recited in claim 1, the computer readable program code means in said article of manufacture further comprising computer readable program code means, wherein when a method M is invoked via a reference to an interface declaration ID.sub.M, said computer readable program code means causes a computer to effect: (i) retrieving from memory said second identifier associated with the interface declaration ID.sub.M ; (ii) generating an index corresponding to said method M based upon said second identifier retrieved from memory, wherein said index identifies an entry in said interface method table corresponding to said method M; (iii) retrieving said entry identified by said index; (iv) invoking said method M using the retrieved entry; (v) retrieving from memory said third identifier associated with said interface declaration IDM, wherein said third identifier identifies an object OM corresponding to said interface declaration ID.sub.M ; and (vi) passing said retrieved third identifier to said method M.

10. An article of manufacture as recited in claim 1, the computer readable program code means in said article of manufacture further comprising computer readable program code means, wherein for each class C.sub.i of objects, the computer readable program code means for causing a computer to effect: storing in memory a class-interface cast table comprising one or more entries each associated with a given interface I1 implemented by said class C.sub.i, wherein each entry identifies offset from a start address of said class method table for said class C.sub.i to an interface table corresponding to said interface I1.

11. An article of manufacture as recited in claim 1, the computer readable program code means in said article of manufacture further comprising computer readable program code means, wherein for each class C.sub.i of objects, the computer readable program code means for causing a computer to effect: storing in memory an interface-interface cast table for each interface I1 implemented by said class C.sub.i, wherein said interface-interface cast table for said interface I1 comprises one or more entries each associated with an interface I2 extended by said interface I1, wherein each entry identifies offset from a start address of said interface method table for said interface I1 to an interface method table corresponding to said interface I2.

12. An article of manufacture as recited in claim 1, the computer readable program code means in said article of manufacture further comprising computer readable program code means, wherein for each interface, the computer readable program code means for causing a computer to effect: storing in memory a function table corresponding to a given interface, wherein said function table stores one or more entries each associated with a given method of said given interface, wherein each entry identifies offset of an entry corresponding to said given method within said interface method table corresponding to said given interface.

13. A program storage device readable by machine, tangibly embodying a program of instructions executable by the machine to perform method steps for representing interface references in an object oriented language, wherein objects correspond to one or more classes, a class is capable of implementing one or more interfaces, an interface is associated with a set of methods, said object oriented language provides for inheritance of said interfaces whereby a first interface may extend one or more other interfaces, and an interface reference IRi is associated with an interface ID IRi and with an object OI corresponding to a class that implements the interface ID IRi, said computer implemented method comprising the steps of: (a) for each class Ci of objects, storing in memory descriptor data corresponding to said class Ci, wherein said descriptor data includes: for each interface declaration IDi implemented by said class Ci, an interface method table containing one of an implementation of a method declared by said interface declaration IDi and an implementation of a method declared by an interface declaration extended by said interface declaration IDi; and (b) for each interface IRi, wherein interface reference IRi is associated with an interface declaration ID IRi and corresponds to a given object OI, storing in memory a first identifier that identifies an interface method table corresponding to the interface ID IRi within the descriptor data for the class corresponding to the object OI, and storing in memory a second identifier that identifies said object OI.

14. A program storing device as recited in claim 13, said method steps further comprising: for each interface reference IR.sub.i, storing in memory a second identifier that identifies said object OI.

15. A program storing device as recited in claim 13, wherein, for each class C.sub.i of objects, said descriptor data corresponding to said class C.sub.i stored in memory includes a class method table comprising one or more entries, wherein each entry identifies an implementation of a method inherited or defined by said class C.sub.i.

16. A program storing device as recited in claim 13, further comprising the step of: (c) for each object O, storing in memory a third identifier for identifying a class method table within said descriptor data associated with a class corresponding to said object O.

17. A program storing device as recited in claim 16, further comprising the step of: (d) when a method M is invoked via a reference to an interface declaration ID.sub.M, (i) retrieving from memory said second identifier associated with the interface declaration ID.sub.M, wherein said second identifier identifies said interface method table corresponding to said interface declaration ID.sub.M ; (ii) generating an index corresponding to said method M based upon said second identifier retrieved from memory, wherein said index identifies an entry in said interface method table corresponding to said method M; (iii) retrieving said entry identified by said index; and (iv) invoking said method M using the retrieved entry.

18. A program storing device as recited in claim 16, further comprising the step of: (d) when a method M is invoked via a reference to an interface declaration ID.sub.M, (i) retrieving from memory said second identifier associated with the interface declaration ID.sub.M ; (ii) generating an index corresponding to said method M based upon said second identifier retrieved from memory, wherein said index identifies an entry in said interface method table corresponding to said method M; (iii) retrieving said entry identified by said index; (iv) invoking said method M using the retrieved entry; (v) retrieving from memory said third identifier associated with said interface declaration IDM, wherein said third identifier identifies an object OM corresponding to said interface declaration ID.sub.M ; and (vi) passing said retrieved third identifier to said method M.

19. A program storing device as recited in claim 13, wherein said descriptor data corresponding to said class C.sub.i is created and stored in memory when said class C.sub.i is declared.

20. A program storing device as recited in claim 13, wherein code for generating said first identifier corresponding to said interface reference IR.sub.i is created and stored in memory upon detection of a statement wherein said object OI is assigned to said interface reference IR.sub.i corresponding to said interface declaration ID.

21. A program storing device as recited in claim 13, wherein code for generating said first identifier corresponding to said interface IRi is created and stored in memory upon detection of a statement wherein an interface reference IR.sub.j is assigned to said interface reference IR.sub.i.

22. A program storing device as recited in claim 13, further comprising the step of: for each class C.sub.i of objects, storing in memory a class-interface cast table comprising one or more entries each associated with a given interface I1 implemented by said class C.sub.i, wherein each entry identifies offset from a start address of said class method table for said class C.sub.i to an interface table corresponding to said interface I1.

23. A program storing device as recited in claim 13, further comprising the step of: for each class C.sub.i of objects, storing in memory an interface-interface cast table for each interface I1 implemented by said class C.sub.i, wherein said interface-interface cast table for said interface I1 comprises one or more entries each associated with an interface I2 extended by said interface I1, wherein each entry identifies offset from a start address of said interface method table for said interface I1 to an interface method table corresponding to said interface I2.

24. A program storing device as recited in claim 13, further comprising the step of: for each interface, storing in memory a function table corresponding to a given interface, wherein said function table stores one or more entries each associated with a given method of said given interface, wherein each entry identifies offset of an entry corresponding to said given method within said interface method table corresponding to said given interface.

25. A computer program product comprising a computer useable medium having computer readable program code means embodied therein for causing interface references in an object oriented language, wherein objects correspond to one or more classes, a class is capable of implementing one or more interfaces, an interface is associated with a set of methods, said object oriented language provides for inheritance of said interfaces whereby a first interface may extend one or more other interfaces, and an interface reference IRi is associated with an interface ID IRi and with an object OI corresponding to a class that implements the interface ID IRi, said computer implemented method comprising the steps of: (a) for each class Ci of objects, storing in memory descriptor data corresponding to said class Ci, wherein said descriptor data includes: for each interface declaration IDi implemented by said class Ci, an interface method table containing one of an implementation of a method declared by said interface declaration IDi and an implementation of a method declared by an interface declaration extended by said interface declaration IDi; and (b) for each interface IRi, wherein interface reference IRi is associated with an interface declaration ID IRi and corresponds to a given object OI, storing in memory a first identifier that identifies an interface method table corresponding to the interface ID IRi within the descriptor data for the class corresponding to the object OI, and storing in memory a second identifier that identifies said object OI.

26. A computer program product as recited in claim 25, further comprising the step of: for each interface reference IR.sub.i, storing in memory a second identifier that identifies said object OI.

27. A computer program product as recited in claim 25, wherein, for each class C.sub.i of objects, said descriptor data corresponding to said class C.sub.i stored in memory includes a class method table comprising one or more entries, wherein each entry identifies an implementation of a method inherited or defined by said class C.sub.i.

28. A computer program product as recited in claim 27, further comprising the step of: (c) for each object O, storing in memory a third identifier for identifying a class method table within said descriptor data associated with a class corresponding to said object O.

29. A computer program product as recited in claim 28, further comprising the step of: (d) when a method M is invoked via a reference to an interface declaration ID.sub.M, (i) retrieving from memory said second identifier associated with the interface declaration ID.sub.M, wherein said second identifier identifies said interface method table corresponding to said interface declaration ID.sub.M ; (ii) generating an index corresponding to said method M based upon said second identifier retrieved from memory, wherein said index identifies an entry in said interface method table corresponding to said method M; (iii) retrieving said entry identified by said index; and (iv) invoking said method M using the retrieved entry.

30. A computer program product as recited in claim 25, wherein said descriptor data corresponding to said class C.sub.i is created and stored in memory when said class C.sub.i is declared.

31. A computer program product as recited in claim 25, wherein code for generating said first identifier corresponding to said interface reference IR.sub.i is created and stored in memory upon detection of a statement wherein said object OI is assigned to said interface reference IR.sub.i corresponding to said interface declaration ID.

32. A computer program product as recited in claim 25, wherein code for generating said first identifier corresponding to said interface IRi is created and stored in memory upon detection of a statement wherein an interface reference IR.sub.j is assigned to said interface reference IR.sub.i.

33. The computer implemented method of claim 26, further comprising the step of: (d) when a method M is invoked via a reference to an interface declaration ID.sub.M, (i) retrieving from memory said second identifier associated with the interface declaration ID.sub.M ; (ii) generating an index corresponding to said method M based upon said second identifier retrieved from memory, wherein said index identifies an entry in said interface method table corresponding to said method M; (iii) retrieving said entry identified by said index; (iv) invoking said method M using the retrieved entry; (v) retrieving from memory said third identifier associated with said interface declaration IDM, wherein said third identifier identifies an object OM corresponding to said interface declaration ID.sub.M ; and (vi) passing said retrieved third identifier to said method M.

34. The computer implemented method of claim 25, further comprising the step of: for each class C.sub.i of objects, storing in memory a class-interface cast table comprising one or more entries each associated with a given interface I1 implemented by said class C.sub.i, wherein each entry identifies offset from a start address of said class method table for said class C.sub.i to an interface table corresponding to said interface I1.

35. The computer implemented method of claim 25, further comprising the step of: for each class C.sub.i of objects, storing in memory an interface-interface cast table for each interface I1 implemented by said class C.sub.i, wherein said interface-interface cast table for said interface I1 comprises one or more entries each associated with an interface I2 extended by said interface I1, wherein each entry identifies offset from a start address of said interface method table for said interface I1 to an interface method table corresponding to said interface I2.

36. The computer implemented method of claim 25, further comprising the step of: for each interface, storing in memory a function table corresponding to a given interface, wherein said function table stores one or more entries each associated with a given method of said given interface, wherein each entry identifies offset of an entry corresponding to said given method within said interface method table corresponding to said given interface.

Patent Citations (12)

Patent	Date	Inventor
US5265206	1993-11-01	Shackelford et al.
US5361350	1994-11-01	Conner et al.
US5367685	1994-11-01	Gosling
US5404525	1995-04-01	Endicott et al.
US5481708	1996-01-01	Kukol
US5493680	1996-02-01	Danforth
US5692183	1997-11-01	Hapner et al.
US5748964	1998-05-01	Goslings
US5758160	1998-05-01	McInerney et al.
US5911074	1999-06-01	Leprince et al.
US5918052	1999-06-01	Krusal et al.
US5953527	1999-09-01	Cable

Non-Patent Literature (17)

"An Object Addressing Mechanism for Statically Typed Languages with Multiple Inheritance", R.C.H. Connor et al., OOPSLA '89 Proceedings, pp. 279-285.
"A Fast Method Dispatcher for Compiled Languages with Multiple Inheritance", R. Dixon et al., OOPSLA '89 Proceedings, pp. 211-214.
"Message Dispatch on Pipelined Processors", K. Driesen et al., ECOOP '95 Proceedings, pp. 252-282.
"Minimizing Row Displacement Dispatch Tables", K. Kriesen et al., OOPSLA '95 Austin, Texas, pp. 141-155.
"Optimizing Dynamically-Typed Object-Oriented Languages with Polymorphic Inline Caches", U. Holzle et al., ECOOP '91 Proceedings, pp. 20-38.
"Bidirectional Object Layout for Separate Compilation", A. Meyers et al., OOPSLA '95, Austin Texas, pp. 124-139.
"Two-directional Record Layout for Multiple Inheritance", W. Pugh et al., Proc. of the ACM SIGPLAN '90 Conference, Jun. 1990, pp. 85-91.
"Fast Dispatch Mechanisms for Stock Hardware", J. Rose et al., OOPSLA '88 Conf. Proc., pp. 27-35.
"Compiling Java, Embedded System Programming", J. Steinhorn, vol. 11, No. 10, Sep. 1998, 42-56.
"The Java Factor", Singhal & Nguyen, Comm. of the ACM, vol. 41, No. 6, Jun. 1998, pp. 35-37.
Boher et al, Distributed object applications, Comm. of the ACM, vol. 41, No. 6, pp. 43-48, Jun. 1998.
Chabert et al, "Java object shariing in Habanero", Comm. of the ACM vol. 41, No. 6, pp. 69-76, Jun. 1998.
Alpern et al, "Implementing Jalapeno in Java", ACM OOPSLA, pp. 314-324, Jul. 1999.
Kreutzer et al, SimJava a framework fro modeling queing networks in Java, Proc. winter simulation, pp. 483-488, 1997.
Miller et al, "Component based simulation environments JSIM as a case study using Java beans", Proc. of winter simulation, pp. 373-381, Jun. 1998.
Chabert et al, "Java object sharing in Haanero", Comm of the ACM, vol. 41, No. 6, pp. 69-76, Jun. 1998.
Bober et al, "Distributed object applications", comm of the ACM, vol. 41, No. 6, pp. 43-48, Jun. 1998.

Abstract

Description