Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1998-12-16
2003-11-18
Hoang, Phuong N. (Department: 2126)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000, C709S241000, C717S148000, C717S162000, C717S163000, C717S164000, C717S165000, C717S166000
Reexamination Certificate
active
06651080
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention relates generally to techniques for developing and delivering virtual machine implementations. More specifically, the invention relates to techniques for creating virtual machine implementations that may be exchanged without requiring modification of the supporting libraries.
The Java™ programming language is an object-based high level programming language developed by Sun Microsystems, Inc. of Palo Alto, Calif., and is designed to be portable enough to be executed on a wide range of computers ranging from small devices (e.g., pagers, cell phones and smart cards) up to supercomputers. Computer programs written in the Java programming language (and other languages) may be compiled into Java virtual machine instructions for execution by a Java virtual machine implementation. In the abstract, a virtual machine interprets virtual machine instructions. That is, the virtual machine decodes and executes the virtual machine instructions. Thus, the Java virtual machine interprets Java virtual machine instructions.
The Java virtual machine is commonly implemented in software by means of an interpreter for the Java virtual machine instruction set, but in general may be software, hardware, or both. Conventional virtual machine interpreters decode and execute the virtual machine instructions of an interpreted program one instruction at a time during execution, e.g., “at runtime,” which is in contrast to compilers that decode source code into native machine instructions prior to execution, e.g., “at compile time,” so that decoding is not performed during execution. Typically, the Java virtual machine implementation and support libraries, which together constitute the Java™ runtime environment, will be written at least in part in a programming language other than the Java programming language (e.g., the C++ programming language).
Computer programs in the Java programming language are arranged in one or ore classes or interfaces (referred to herein jointly as classes). Such programs are generally platform, i.e., hardware and operating system, independent. As such, these computer programs may be executed, unmodified, on any computer that is able to run an implementation of the Java™ runtime environment. A class written in the Java programming language is compiled to a particular binary format called the “class file format” that includes Java virtual machine instructions for the methods of a single class. In addition to the Java virtual machine instructions for the methods of a class, the class file format includes a symbol table as well as other ancillary information associated with the class.
A conceptual view of a conventional implementation of the Java runtime environment is shown in FIG.
5
. As seen therein, the Java runtime environment
251
includes support libraries
253
and executable program
257
incorporating a Java virtual machine implementation
255
. Support libraries
253
are also known as built-in or standard class libraries. Support libraries
253
include Java methods that may be implemented through the use of native functions. Such native functions may be delivered, in addition to Java virtual machine implementation
255
, as part of executable program
257
. The native functions in executable program
257
typically include functions for controlling the virtual machine and for providing platform specific functions like I/O, graphical windowing, networking, and the like. It should be appreciated that the native functions may be written in any number of different languages and are typically written in a language other than the Java programming language.
Java virtual machine implementation
255
also includes a class loader and a verifier. There is typically no clear interface between the class loader or class verifier portions of a Java virtual machine implementation and the remainder of that virtual machine implementation. Similarly, there is typically no clear interface between the native functions and the virtual machine implementation because the various components of the Java runtime environment may be designed at the same time. Accordingly, the class loader, verifier, and native functions may be written with assumptions about the Java virtual machine implementation. For example, they may be written to utilize specific data structures used within the Java virtual machine implementation. If a developer desires to change the Java virtual machine implementation, a substantial amount of time may be required to rewrite or modify the class loader, verifier, and native functions to work with the new Java virtual machine implementation.
The support libraries
253
may also include additional native functions or other methods that are at least partially dependent on the specific implementation of the Java virtual machine utilized in the Java runtime environment. For example, many operations that the support libraries perform require access to data structures managed by the Java virtual machine or services provided by the Java virtual machine (e.g., threads). In conventional implementations this significantly limits the modularity of the support libraries since any class library that includes an implementation dependent function would potentially have to be rewritten or modified to accommodate a new Java virtual machine implementation.
It view of the foregoing, it would generally be desirable to provide a modular runtime environment architecture where the functionality provided by the support libraries may be shared by multiple virtual machine implementations. It would also be desirable to provide innovative techniques of developing and delivering virtual machine implementations that would allow virtual machines to be exchanged with essentially no impact on the support libraries. Conversely, it would be desirable to facilitate the exchange of support library implementations with essentially no impact on the virtual machine implementations.
SUMMARY OF THE INVENTION
In general, embodiments of the present invention provide innovative techniques for developing and exchanging virtual machine implementations and/or support library implementations. As an example, in one embodiment of the invention, the virtual machine design specifies a set of functions for executing all or substantially all support library operations that are dependent on the implementation of the virtual machine. When a developer desires to substitute one virtual machine implementation for another, the developer is able to basically “plug-in” the second virtual machine implementation with minimal impact on the support libraries since both virtual machine implementations provide implementations for the set of specified functions that are dependent on the implementation of the respective virtual machine. This allows the developer great flexibility in exchanging the virtual machine implementation. Several embodiments of the invention are described below.
In one embodiment, a method for developing virtual machine implementations includes providing an interface as part of the virtual machine design that specifies functions that may be called by functions which are part of the support library implementations. The set of functions that essentially make up the interface execute all or substantially all operations utilized by the support libraries that are dependent on the implementation of the virtual machine. The set of functions may include operations that control a virtual machine implementation, access data managed by the virtual machine, and perform input/output (I/O) operations.
As the interface specifying all or substantially all of the operations utilized by the support libraries that are dependent on the implementation of the virtual machine has been specified in the design of the virtual machine, the same implementation of the support libraries may be readily utilized by any of several implementations of the virtual machine. Accordingly, one of two virtual machine implementations may be easily replaced with the other. In other words, the virtual machine
Liang Sheng
Lindholm Timothy G.
Beyer Weaver & Thomas LLP
Follansbee John
Hoang Phuong N.
Sun Microsystems Inc.
LandOfFree
Techniques for implementing pluggable virtual machines does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Techniques for implementing pluggable virtual machines, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Techniques for implementing pluggable virtual machines will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3145009