Expanded memory space in environments including virtual machines

[0001] This application is a continuation in part of U.S. patent application Ser. No. 10/378,061 entitled SEGMENTED VIRTUAL MACHINE filed Feb. 28, 2003, which is incorporated herein by reference for all purposes.

[0002] The present invention relates generally to computer programming. More specifically, a technique of data access is disclosed.

[0003] Computer systems usually have limited memory addressing capabilities. The typical processor or system is designed to allow processes to address memory in a memory space up to a certain size limit. Software applications are often compiled to operate within the limited memory space. It is often difficult or expensive to upgrade such systems when the next generation systems with increased memory size limit become available. For example, many of the existing systems support a 32-bit architecture that limits the addressable memory space of processes to approximately 2³², or 4 gigabytes. As programs become more sophisticated and consume more memory, 4 gigabytes of memory space may become inadequate. The next generation 64-bit systems provide much greater memory addressing capabilities, however, migrating from 32-bit systems to 64-bit systems tend to be an expensive proposition because of the software upgrades required. Since many applications are compiled specifically for one type of system, upgrading from a 32-bit system to a 64-bit system would typically require that these legacy 32-bit applications be replaced with new applications specifically compiled for the 64-bit platform, therefore increasing the cost of the upgrade.

[0004] Some systems that include multiple software components configured to collaborate in 32-bit environments face additional barrier to upgrades. For example, an application may interact with drivers or libraries to perform desired functions in a 32-bit environment. If any of the components is not available for the 64-bit platform, it is likely that the system as a whole cannot successfully migrate to a 64-bit system.

[0005] It would be desirable if legacy software can take advantage of the larger memory space supported by newer systems. It would also be desirable if software components configured to operate in environments that support different memory space sizes can interoperate transparently, without requiring recompilation.

[0015] The invention can be implemented in numerous ways, including as a process, an apparatus, a system, a composition of matter, a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or electronic communication links. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.

[0016] A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.

[0017] A data access technique is disclosed. In some embodiments, a set of computer instructions is executed in a first environment that has limited addressing capability to address memory up to a size limit. Data is specified in a memory space of a second environment, where the memory space has a size that exceeds the size limit. The data specified in the memory space of the second environment may be accessed from the first environment using the limited addressing capability of the first environment.

[0018] FIG. 1 is a system diagram illustrating an application configured to operate in an environment with limited memory addressing capabilities, according to some embodiments. In this example, environment 100 allows its processes to address up to 32 bits of memory. As used herein, an environment refers to the hardware platform, the operating system, as well as other appropriate hardware, firmware, software components and combinations thereof that allow computer instructions to be executed. The memory space associated with an environment refers to the range of memory that can be addressed by computer instructions operating in the environment. Virtual memory techniques are sometimes used to address the memory space. In the example shown, environment 100 is a 32-bit environment, which means that the memory space addressable by computer instructions operating in environment 100 is limited to 32 bits. An application 104 executes within a 32-bit virtual machine (VM) 102. Examples of environments that support virtual machine include Java, Microsoft .NET, etc. As shown, the application can directly address no more than the maximum amount of memory addressable by the virtual machine, which is approximately 4 gigabytes in this example.

[0019] FIG. 2 is a diagram illustrating an application operating in a segmented virtual machine embodiment. In this example, an application such as application 104 of FIG. 1 is configured to operate in a 64-bit environment, within a segmented VM. The segmented VM shown in this example may be implemented using the techniques described in U.S. patent application Ser. No. 10/378,061 entitled SEGMENTED VIRTUAL MACHINE filed Feb. 28, 2003, which is incorporated herein by reference above. In some embodiments, a segmented virtual machine includes a shell VM and a core VM. The core VM is configured to perform VM internal execution functions such as memory management, data processing, data transfer, etc. The shell VM is configured to perform shell VM functions such as interfacing with the external environment, communicating with the core VM, etc. The shell VM and the core VM may reside on the same device, or on separate devices.

[0020] In the example shown, in a 64-bit environment 206, application 104 cooperates with a 64-bit core VM 204, which cooperates with a 32-bit shell VM 200. The shell VM operates in a 32-bit environment 202 that includes components capable of addressing up to 32 bits of memory. The bit numbers of the environments are chosen for the purposes of example; other numbers may be used in other embodiments. The 64-bit and 32-bit environments may be configured to operate on separate devices. For example, the 32-bit environment of some embodiments includes an IA32 processor based system that supports operating systems such as Linux, Windows, etc., while the 64-bit environment includes specialized hardware designed to provide greater processing power and resources. In some embodiments, the 64-bit and 32-bit environments reside on a single device such as a SPARC Server that is capable of supporting both environments. By using a segmented VM, existing 32-bit legacy software can be reused when other parts of the system migrate to 64-bit platform.

[0021] In this example, application 104 is written in a portable language such as Java that does not directly manipulate the memory addresses and uses references to address objects and their associated memory. As a result, application 104 does not need to be recompiled or substantially modified in order for it to execute in the 64-bit environment. Objects allocated by application 104 can be indirectly accessed or referenced from native code the 32-bit environment by handles residing in the shell VM. Although the handles in this example are limited to 32 bits, the objects referenced by the handles may occupy up to 64 bits of memory. For example, objects 216 and 218 are allocated in the memory space of the 64-bit environment and can be referenced from the 32-bit environment by handles 216 and 218, respectively. By using handles to reference objects in the core VM from the shell VM, data specified in a 64-bit memory space may be accessed from a 32-bit environment, even though the 64-bit memory space size exceeds the size limit that the 32-bit environment is capable of directly addressing.

[0022] For the purposes of illustration, accessing objects using object handles is discussed extensively throughout the specification, although by using similar techniques, other structures may be accessed via appropriate references. For example, according to some embodiments, methods or functions can be allocated in a 64-bit core VM and referenced by method identifiers that reside in a 32-bit shell VM. In some embodiments, fields of objects are allocated on the 64-bit core VM and are referenced by field identifiers that reside in the 32-bit shell VM.

[0023] FIG. 3 is a system diagram illustrating another system configured to operate in an environment with limited memory addressing capabilities. In this example, in a 32-bit environment 410, an application 400 operates within a 32-bit VM 402. A native library 408 cooperates with the virtual machine to perform functions and instructions that are specific to the 32-bit environment. In the system shown, the 32-bit native library requires recompilation in order to operate in a 64-bit environment. However, recompilation may not be feasible in some cases due to factors such as lack of access to the source code. In the example below, a segmented virtual machine allows application 400 to operate in a 64-bit environment and take advantage of the greater memory space without requiring the 32-bit native library to be recompiled.

[0024] FIG. 4 is a diagram illustrating another segmented virtual machine example. In this example, application 400 is configured to execute in a 64-bit environment 506. The application is able to invoke native library 408, which is configured to execute in a 32-bit environment 508. The application cooperates with a segmented virtual machine that includes a 64-bit core VM 502 and a 32-bit shell VM 504, operating in environments 506 and 508, respectively. Objects allocated by the application reside in the 64-bit environment, within the 64-bit core VM. The objects are referenced in the shell VM via 32-bit handles such as 514 and 516. In some embodiments, an object can also be referenced via a 64-bit handle in the 64-bit core VM. When the core VM is ready to invoke instructions in the shell VM, the 64-bit handles of one or more objects associated with the instructions are translated to the corresponding 32-bit handles, and a reverse translation takes place when the shell VM is ready to invoke instructions in the core VM. Thus, the native library operating in the 32-bit environment can be invoked by the application to operate on objects allocated in the 64-bit environment and vice versa. Details of the operation are discussed below.

[0025] Native interface calls such as Java Native Interface (JNI) calls and callbacks are sometimes used to facilitate calls between the native library and the application. FIG. 5 is a flowchart illustrating a callback from the native library to the application, according to the embodiment shown in FIG. 4. In this example, the native library initiates a call to the application by making a native interface callback. The shell VM receives a native interface callback made by the native code on the shell VM device (550), and relays the call to the core VM (552). The core VM processes the call and performs any logic necessary to produce the desired result (554). The core VM sends the result back to the shell VM (556), and the shell VM relays the result back to the native code on the shell VM device (558).

[0026] FIG. 6 is a flowchart illustrating the processing of a function call by a segmented virtual machine, according to the embodiment shown in FIG. 4. In this example, application 400 makes a native interface call to invoke a function supported by native library 408. The call is sent to the core VM. Upon receiving the native interface call from the application, the core VM forwards the call to the shell VM (650). The shell VM then forwards the native interface call to the native libraries on the shell VM device, which perform operations according to the native interface call (652). The shell VM receives the result from the function call to the native libraries (654). The shell VM then relays the result to the core VM (656), which performs further processing if necessary (658).

[0027] FIG. 7 is a flowchart illustrating in detail the processing of a native library call according to the example shown in FIG. 6. In this example, the processing of a library function call, f(A, B)=B.z=A.x+B.y, is used to illustrate the cooperation among the application, the segmented virtual machine and the native library. Application 400 calls the library function, and 64-bit handles for objects A and B are passed to the function call in the core VM (600). The 64-bit handles are then translated into 32-bit handles (602). In this example, application 400 is a Java application and objects A and B are global objects. The handles for these global objects are allocated from a specific region in the memory space. The starting point of this memory region is referred to as a base address. In some embodiments, to derive a 32-bit handle from a 64-bit handle, the base address is subtracted from the 64-bit handle. The core VM then invokes the native library by sending a native interface call to the shell VM. The 32-bit handles for objects A and B are passed to the native interface call (604). The shell VM then invokes the 32-bit native library function using the 32-bit handles (606). The library performs the function as required (608). Details of how the library performs the function are discussed below. The results are then returned to the application (610).

[0028] FIG. 8 is a flowchart illustrating the details of how the library function is performed according to some embodiments (608 of FIG. 6). In this example, the native library function, f(A, B)=B.z=A.x+B.y is invoked and executed. The native library performs a GET operation to obtain the values of A.x and B.y, then performs a PUT operation to update the value of B.z. To get the value of A.x, the library function requests A.x from shell VM (700). The shell VM passes the request of A.x to the core VM (702), and the core VM responds with the value of A.x (704). To get the value of B.y, the library function requests B.y from the shell VM (706). The shell VM passes the request for B.y to the core VM (708), and the core VM responds with the value of B.y (710). To perform the PUT function, the library function requests the shell VM to deposit the sum in B.z (712). The shell VM then requests the core VM to deposit the sum in B.z (714). The core VM deposits the sum as requested (716) and acknowledges the deposit (718).

[0029] A data access technique has been disclosed. For the purposes of example, accessing data in a 64-bit memory space from a 32-bit environment is discussed extensively throughout this specification, although the technique is also applicable to data access between two or more environments with different memory addressing capabilities.

[0030] Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.