Electrical computers and digital processing systems: interprogra – Dynamic linking – late binding – Object oriented dynamic linking – late binding
Reexamination Certificate
2000-05-31
2004-05-18
An, Meng-Al T. (Department: 2126)
Electrical computers and digital processing systems: interprogra
Dynamic linking, late binding
Object oriented dynamic linking, late binding
C718S001000
Reexamination Certificate
active
06738977
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to sharing classes between first and second virtual machines, and in particular to a way in which a class loaded into a first virtual machine can be shared with a second virtual machine.
BACKGROUND OF THE INVENTION
Programs written in the Java programming language (Java is a trademark of Sun Microsystems Inc) are generally run in a virtual machine environment, rather than directly on hardware. Thus a Java program is typically compiled into byte-code form, and then interpreted by the Java virtual machine (JVM) into hardware commands for the platform on which the JVM is executing. The JVM itself is an application running on the underlying operating system. An important advantage of this approach is that Java applications can run on a very wide range of platforms, providing of course that a JVM is available for each platform.
Java is an object-oriented language. Thus a Java program is formed from a set of class files having methods that represent sequences of instructions (somewhat akin to subroutines). A hierarchy of classes can be defined, with each class inheriting properties (including methods) from those classes (termed superclasses) which are above it in the hierarchy. At run-time objects are created as instantiations of these class files, and indeed the class files themselves are effectively loaded as objects. One Java object can call a method in another Java object. In recent years Java has become very popular, and is described in many books, for example “Exploring Java” by Niemeyer and Peck, O'Reilly & Associates, 1996, USA, and “The Java Virtual Machine Specification” by Lindholm and Yellin, Addison-Wedley, 1997, USA.
The standard JVM architecture generally supports only a single application, although this can be multi-threaded. In a server environment used for database transactions and such-like, each transaction is typically performed as a separate application, rather than as different threads within an application. This is to ensure that every transaction starts with the JVM in a clean state. In other words, a new JVM is started for each transaction (i.e. for each new Java application). Unfortunately however this results in an initial delay in running the application (the reasons for this will be described in more detail later). The overhead due to this frequent starting and then stopping of JVMs as successive transactions are processed is therefore significant, and seriously degrades the scalability of Java server solutions.
Various attempts have been made to mitigate this problem. EP-962860-A describes a process whereby one JVM can fork into a parent and a child process, this being quicker than setting up a fresh JVM. Another approach is described in “Oracle JServer Scalability and Performance” by Jeremy Litzt, July 1999 (see: oracle.com/database/documents/jserver_scalabilit y_and_performance_twp.pdf). Thus the JServer product available from Oracle Corporation, USA, supports the concept of multiple sessions (a session effectively representing a transaction or application), each session including a JServer session. Resources such as read-only bytecode information are shared between the various sessions, but each individual session appears to its JServer client to be a dedicated conventional JVM.
U.S. patent application Ser. No. 09/304160, filed Apr. 30, 1999 (“A Long Running Reusable Extendible Virtual Machine”), assigned to IBM Corporation, discloses a virtual machine (VM) having two types of heap, a private heap and a shared heap. The former is intended primarily for storing application classes, whilst the latter is intended primarily for storing system classes and, as its name implies, is accessible to multiple VMs. The idea is that as each new VM is launched, it can access system classes already in the shared heap, without having to reload them, relink them, and so on, thereby saving significantly on start-up time. The shared memory can also be used for storing application classes that will be used by multiple VMs, with the private heap then being used for object instances specific to a particular application running on a VM. At termination of a VM its private heap is deleted, but the shared heap persists and remains available to other VMs.
A related idea is described in “Building a Java virtual machine for server applications: the JVM on OS/390” by Dillenberger et al, IBM Systems Journal, Vol 39/1, January 2000. This describes two types of JVM, a resource-owning JVM which loads and resolves necessary system classes, and subsequent “worker” JVMs which can reuse the resolved classes. Again this implementation uses a shared heap to share system and potentially application classes for reuse by multiple workers, with each worker JVM also maintaining a private or local heap to store data private to that particular JVM process. It is suggested that worker JVMs use a common class loader to share name spaces across a set of JVMs.
However, one problem here is that a worker JVM may potentially delete all references to a class loader, which is the owner of some or all of the commonly loaded classes. This makes the loader unreachable, so that it and its classes may be garbage collected, for subsequent reloading and initialisation. Unfortunately, this is not compatible with the fact that the class loader and the classes it has loaded are effectively shared between a number of JVMs.
SUMMARY OF THE INVENTION
Accordingly, the present invention provides a method of operating a system including first and second virtual machines and having a shared memory accessible to both said first and second virtual machines, the method comprising the steps of:
loading a class within the first virtual machine =into said shared memory, said class having sharable and non-sharable data associated therewith; loading the class into the second virtual machine by locating the class within said shared memory; forming a mirror of the class within a private memory in the second virtual machine; and completing the non-sharable data associated with the class in said mirror; and
utilising the class in the second virtual machine on the basis of the sharable data from the shared memory of the first virtual machine, and the non-sharable data from the private memory of the second virtual machine.
The invention provides a master (first) virtual machine and at least one client (second) virtual machine running in parallel on the same computer system. Certain resources from the master virtual machine can be shared with the client virtual machine, thereby greatly improving efficiency. In particular the client virtual machine does not generally have to load classes already loaded by the master virtual machine. However, in accordance with the present invention it is realised that this sharing cannot be complete because certain class properties (eg initialisation status—see below) may need to be set individually on each virtual machine. Thus for each class to be shared, a mirror version is created on a client virtual machine. The mirror version of the class is effectively a composite in that certain class data is stored locally on the client virtual machine, whilst other class data is actually shared with the copy of the class loaded into shared memory by the first virtual machine. It will be appreciated that overall the mirror version contains essentially the same data elements as the original class in the first virtual machine (since both are derived ultimately from the same class file). Those elements for which the master and client will contain identical data can be shared, and only a single copy in the master need be maintained. Those elements which either do or are liable to contain different data in the client from the master must be present locally in the mirror itself. It will be appreciated therefore that the mirror is not a strict duplicate of the class loaded into the master. Rather it is the same class loaded into a different virtual machine (and so may have different data element values, etc), but which reuses certain data from the class a
Berry Robert F.
Dillenberger Donna N.
Hutchison Elizabeth A.
Paice Susan P.
Schmidt Donald W.
An Meng-Al T.
Morris, Esq. Daniel P.
Scully Scott Murphy & Presser
Zhen Li B.
LandOfFree
Class sharing between multiple 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 Class sharing between multiple virtual machines, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Class sharing between multiple virtual machines will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3252237