Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1999-04-30
2004-02-17
Follansbee, John (Department: 2126)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000
Reexamination Certificate
active
06694346
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to virtual data Processing machines and, in particular, to a method and apparatus for enabling such virtual data Processing machines to keep their state across invocations, to amortize initialization and runtime costs, to avoid garbage collection and Process termination and to provide greater application security, isolation and availability.
BACKGROUND OF THE INVENTION
Virtual machines are created within a Process for the purpose of loading and running an application. As is known, a “Process” isolates resources that are allocated to a particular program during runtime and prevents multiple programs from interfering with each other's execution. At the termination of execution of an application program, the entire Process is torn down.
As virtual machine applications increase, it is desirable to retain the virtual machine so as to enable it to execute a next application program. This can save the expensive costs of Process tear down and start up. For example, prior art computer systems may need to execute between 5 million and 40 million lines of code to reestablish a virtual machine and a Process. Having a long running, reusable virtual machine also saves the cost of class linking, loading and initialization which are also expensive in terms of use of computational facilities. Avoiding the creation of a virtual machine environment, per application, also increases the volume and throughput of applications a system can manage.
Currently, virtual machines are uniProcess and begin and end when the application completes. The prior art has suggested various ways to keep the state of a virtual machine in existence. One suggested solution is to maintain a pool of virtual machine Processes. Another is to “check point” a virtual machine's state (i.e., to retain for subsequent use a copy of all machine values that the machine has set). A further solution is to maintain a pool of virtual machines and to send objects created in one virtual machine to the “heap” (i.e., an allocated area of memory) of another virtual machine.
Maintaining a pool of virtual machines does not diminish an initialization path length of a virtual machine. Scheduling of application programs in a previously created virtual machine hides the path length from a client request, but does not reduce class linking, loading or initialization requirements nor does it obviate a need to bring up and tear down a Process for each application.
Check pointing a virtual machine's state and applying it to new Processes requires pointer and offset readjustments that are costly in path length and may not be possible in systems where a range of addresses a Process will command cannot be guaranteed.
Reuse of a same virtual machine Process for multiple applications does not guarantee a clean heap nor a writable static area of memory (i.e., predefined fields with assigned integer values) for each application that runs consecutively in the virtual machine.
Maintaining a pool of virtual machines and “function shipping” an application program to a correct virtual machine or sending the correct object to the virtual machine (where the application is running) requires a cache coherency scheme, incurs extra overhead and possibly network flows to pass the application or object. Moreover, this procedure does not guarantee that the memory space in each virtual machine is devoid of values left by previous applications.
Accordingly, it is an object of the present invention to provide a long running, reusable, extensible, virtual machine to run application programs.
Another object of the present invention is to obviate the need to tear down and bring up a new virtual machine to insure that dynamic or static memory values set by a previous application program are no longer present.
Yet another object of the present invention is to initialize a virtual machine once and to reuse this initialization state across subsequent virtual machine Processes.
A further object of the present invention is to load, link, verify, and compile a class once and to reuse this class data across subsequent virtual machine Processes.
A still further object of the present invention is to invoke the initialization methods of a class once and to reuse this class data across subsequent virtual machine Processes.
Yet another object of the present invention is to be able to run multiple applications in a long running virtual machine and have each application isolated from each other, increasing the availability of the virtual machine.
Still another object of the present invention is to separate a virtual machine's state into different heaps: private and shared, which enable application isolation, more efficient garbage collection and an ability to extend the virtual machine's runtime.
Another object of the present invention is to obviate the need for garbage collection on a virtual machine's private state.
SUMMARY OF THE INVENTION
An architecture for a virtual machine which can be persistent through multiple applications includes a shared heap where requisite runtime classes to bring the virtual machine into a ‘ready’ mode are loaded, linked, verified, initialized and compiled. Subsequent virtual machines are started and use the contents of the shared heap where the necessary system classes have already been loaded and initialized. Application lasses are loaded into the shared heap, allowing subsequent applications to reuse these classes without the cost of reloading. relinking, reverifying and recompiling the classes. Application programs create their objects in “private heaps”. At the end of execution of the application, the private heap is reinitialized. No garbage collection (i.e., a method for finding unused memory) need occur on the private heap.
Static initializers are methods that create predefined values (hereafter “static values”) that are maintained in a persistent area of the private heap. This persistent area is is not reset to a common value, but rather is reset to its initial values, between execution of applications. This action obviates the need to terminate the virtual machine Process. If applications “misbehave” (i.e. open or create external Process related resources, e.g., threads, file descriptors, etc.), the virtual machine Process is terminated to insure complete clean up of those resources. However, the shared heap is not deleted and can be used by subsequent virtual machines. These subsequent virtual machines save the overhead of reloading, relinking, recompiling, reverifying any of the classes needed for runtime initialization or any of the application classes that have been used previously.
This architecture has the effect of a long running, reusable, virtual machine, because classes, once loaded, need not be loaded or initialized again.
REFERENCES:
patent: 5247681 (1993-09-01), Janis et al.
patent: 5375241 (1994-12-01), Walsh
patent: 5999732 (1999-12-01), Bak et al.
patent: 6167535 (2000-12-01), Foote et al.
patent: 6332218 (2001-12-01), Walker et al.
patent: 6363409 (2002-03-01), Hart et al.
Klemm, “Practical Guidelines for Boosting Java Server Performance”, ACM, 1999.*
Atkinson et al., Providing Orthogonal Persistence for Java Extended Abstract, Jul. 1998, LNCS 1445, pp. 383-395.*
Davis, Build your own ObjectPool in Java to bosst app speed, Jun. 1998, Java World.*
Dale Rogerson, 1997, Microsoft Press, “Inside COM —Microsoft's Component Object Model”, pp. 85-100.*
Jay Munro, Jun. 1992, PC Magazine, v11, n11, p379(6), “Writing DLLs for Windows using Visual Basic, part 1”.
Aman Jeffrey D.
Bordawekar Rajesh R.
Brown Michael Wayne
Dillenberger Donna Ngar-Ting
Emmes David B.
Cao Diem
Follansbee John
International Business Machines - Corporation
Morris Daniel P.
Ohlandt Greeley Ruggiero & Perle L.L.P.
LandOfFree
Long running, reusable, extendible, virtual machine does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Long running, reusable, extendible, virtual machine, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Long running, reusable, extendible, virtual machine will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3318681