Method and apparatus for managing independent asynchronous I/O operations within a virtual machine

One embodiment of the present invention provides a system that facilitates performing independent asynchronous I/O operations within a platform-independent virtual machine. Upon encountering an I/O operation, a language thread within the system marshals parameters for the I/O operation into a parameter space located outside of an object heap of the platform-independent virtual machine. Next, the language thread causes an associated operating system thread (OS-thread) to perform the I/O operation, wherein the OS-thread accesses the parameters from the parameter space. In this way, the OS-thread does not access the parameters in the object heap directly while performing the I/O operation.

BACKGROUND

1. Field of the Invention

The present invention relates to techniques for managing Input/Output (I/O) operations within a computer system. More specifically, the present invention relates to a method and an apparatus for performing independent asynchronous I/O operations within a platform-independent virtual machine within a computer system.

2. Related Art

The exponential growth of the Internet has in part been fueled by the development of computer languages, such as the JAVA™ programming language distributed by Sun Microsystems, Inc. of Santa Clara, Calif. The JAVA programming language allows an application to be compiled into a module containing platform-independent byte codes, which can be distributed across a network of many different computer systems. Any computer system possessing a corresponding platform-independent virtual machine, such as the JAVA virtual machine, is then able to execute the byte codes. In this way, a single form of an application can be easily distributed to and executed by a large number of different computing platforms.

These platform-independent virtual machines are presently being incorporated into smaller pocket-sized computing devices, such as personal organizers. Unfortunately, memory space is severely constrained within these pocket-sized computing devices. Hence, system designers must use as little memory space as possible in implementing virtual machines within these pocket-sized computing devices.

Platform independent virtual machines typically provide run-time support for multiple “language threads” (L-threads). For example the JAVA virtual machine supports the execution of multiple JAVA threads. In larger computer systems it is practical to implement L-threads using a one-to-one mapping with underlying operating system threads (OS-threads). However, memory-constrained computing devices often lack the virtual memory capabilities to make this possible. Furthermore, a one-to-one mapping requires a large number of OS-threads, which can consume a large amount of memory space.

For this reason, in memory-constrained systems L-threads are often implemented as co-routines that share a single OS-thread. Unfortunately, if multiple L-threads share a single OS-thread, implementing I/O operations can be a problem because an I/O operation can potentially cause the single OS-thread to block, even if other L-threads are waiting to perform useful work. To remedy this problem, some systems pair an L-thread with an extra OS-thread during the time the L-thread is performing an I/O operation. In way, the extra OS-thread can perform the I/O operation on behalf of the L-thread, and the L-thread is de-scheduled until the OS-thread completes the I/O operation. After the I/O operation completes, the OS-thread is returned to the shared pool, which allows the OS-thread to be reused.

In order to perform the I/O operation, the OS-thread typically manipulates parameters for the I/O operation located in an object heap within the virtual machine. This creates problems because the object heap is typically subject to periodic garbage collection operations, which can potentially move the parameters within the object heap. Hence, the OS-thread must acquire a garbage collection (GC) lock while accessing the object heap to ensure that garbage collection operations do not cause the OS-thread to access the wrong locations in the object heap. Moreover, allowing the OS-thread to access the object heap generally reduces system reliability because the OS-thread can potentially corrupt the object heap.

Hence, what is needed is a method and an apparatus for performing I/O operations within a platform-independent virtual machine without the problems listed above.

SUMMARY

One embodiment of the present invention provides a system that facilitates performing independent asynchronous I/O operations within a platform-independent virtual machine. Upon encountering an I/O operation, a language thread within the system marshals parameters for the I/O operation into a parameter space located outside of an object heap of the platform-independent virtual machine. Next, the language thread causes an associated operating system thread (OS-thread) to perform the I/O operation, wherein the OS-thread accesses the parameters from the parameter space. In this way, the OS-thread does not access the parameters in the object heap directly while performing the I/O operation.

In a variation on this embodiment, after the OS-thread finishes the I/O operation, the language thread unmarshals parameters from the parameter space and then returns from the I/O operation.

In a variation on this embodiment, marshalling the parameters involves marshalling the parameters from the object heap, and unmarshalling the parameters involves unmarshalling the parameters into the object heap.

In a variation on this embodiment, the platform-independent virtual machine operates in accordance with a hybrid thread model in which language threads that are not performing I/O operations execute as co-routines on a single OS-thread, and wherein language threads performing I/O operations are associated with dedicated OS-threads that perform the I/O operations.

In a variation on this embodiment, the parameter space is associated with the OS-thread and is allocated from a global pool of memory located outside of the object heap.

In a variation on this embodiment, the parameter space is associated with the OS-thread and is allocated in an unused end of the object heap.

In a variation on this embodiment, the parameter space is allocated in stack space associated with the OS-thread.

DETAILED DESCRIPTION

Computing Device

FIG. 1illustrates a computing device110coupled to a development system106in accordance with an embodiment of the present invention. Development system106can generally include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a personal organizer, a device controller, and a computational engine within an appliance. Development system106contains development unit108, which includes programming tools for developing platform-independent applications.

Development system106is coupled to computing device110through a communication link112. Computing device110can include any type of computing device or system including, but not limited to, a mainframe computer system, a server computer system, a personal computer, a workstation, a laptop computer system, a pocket-sized computer system, a personal organizer and a device controller. Computing device110can also include a computing device that is embedded within another device, such as a pager, a cellular telephone, a television, an automobile, or an appliance.

Communication link112can include any type of permanent or temporary communication channel that may be used to transfer data from development system106to computing device110. This can include, but is not limited to, a computer network such as an Ethernet, a wireless communication network or a telephone line.

Computing device110includes data store114, for storing code and data, as well as a virtual machine116for processing platform-independent programs retrieved from data store114.

During the development process, a class file118is created within development unit108. Class file118contains components of a platform-independent program to be executed in computing device110. For example, class file118may include methods and fields associated with an object-oriented class. Next, class file118is transferred from development unit108through communication link112, into data store114within computing device110. This allows virtual machine116to execute an application that accesses components within class file118. Note that virtual machine116can generally include any type of virtual machine that is capable of executing platform-independent code, such as the JAVA VIRTUAL MACHINE™ developed by SUN Microsystems, Inc. of Palo Alto Calif.

Virtual machine116is implemented on top of an underlying operating system170. More specifically, virtual machine116is implemented using a number of native OS-threads160within operating system170, which are represented by the letters “OS”. Note that operating system170can generally include any type of operating system for a computing device that supports multiple native OS-threads.

Virtual machine116includes an interpreter120, which interprets platform-independent code from data store114during program execution. Virtual machine116can alternatively execute compiled code. This compiled code is produced by compiling platform-independent code into native code for computing device110.

Virtual machine116also includes object heap122for storing objects that are manipulated by code executing on virtual machine116.

Virtual machine116also supports multiple language threads (L-threads), which are represented by the letter “L”, as well as multiple pool threads, which are represented by the letter “P”. These pool threads can be implemented as objects that provide handles for interacting with associated native OS-threads (represented by the letters “OS”) within operating system170. (InFIG. 1, pool threads are connected by solid lines to their associated native threads.)

As is illustrated inFIG. 1, some of the L-threads are active L-threads130, which execute as co-routines on a single OS-thread161. Other L-threads are I/O threads140, which are associated with on-going I/O operations. These L-threads are paired with corresponding pool threads, which act as handles for associated OS-threads that perform the I/O operations. There are also a number of unused pool threads150, which are not associated with L-threads.

When one of the active L-threads130encounters an I/O operation, the L-thread is paired with a pool thread from the unused pool threads150. This pool thread acts as a handle for a native OS-thread within the underlying operating system170, which performs the I/O operation. At this point, the L-thread is no longer one of the active threads, but instead becomes one of the I/O threads140. After the I/O operation is complete, the L-thread returns to being one of the active L-threads130and the pool thread returns to being one of the unused pool threads150.

Note that the term “I/O operation” as used in this specification and the appended claims refers to any type of operation with a long and/or unpredictable duration, which may cause a thread to block. Hence, the term “I/O operation” is not meant to be limited to only input of output operations. For example, an I/O operation can include a long computational operation, which is sent to a co-processor, and which may not return from the co-processor for a long period of time.

I/O Operation Parameters

FIG. 2illustrates how parameters are marshaled and unmarshalled in accordance with an embodiment of the present invention. When a language thread (L-thread)201encounters an I/O operation, L-thread201marshals one or more parameters for the I/O operation into parameter space203, which is associated with a native OS-thread202. For example, inFIG. 2, a value referenced by a pointer x in object heap122is marshaled into a field205in parameter space203.

When the I/O operation is complete, one or more parameters from the I/O operation are unmarshalled from parameter space203. For example, inFIG. 2, a value from a field206in parameter space203is unmarshalled into a location in object heap122referenced by a pointer y.

FIG. 3presents a flow chart illustrating actions performed by a language thread (L-thread)201during an I/O operation in accordance with an embodiment of the present invention. Upon encountering an I/O operation, L-thread201calls the function getParameter, which is implemented by OS-thread202. The function getParameter returns a pointer to a parameter space203that contains parameters for the I/O operation (step302).

In one embodiment of the present invention, parameter space203is a fixed-position memory block that is allocated for the purpose of marshalling data into and unmarshalling result data out of. This memory block can come from a number of sources. (1) It can be allocated from a global pool of memory located outside of the object heap. (2) It can be allocated in an unused end of the object heap. Or, (3) it can be allocated in stack space belonging to the associated native OS-thread.

L-thread201then blocks (step312) and returns (step314). This causes L-thread201to go to sleep and also causes the associated OS-thread202to perform the I/O operation.

Note that the associated OS-thread202continually executes a loop, such as the loop below.

declare parameterSpace[];loop {wait(execEvent);(*f)(p);}
This loop causes OS-thread202to wait for an execEvent, such as L-thread201blocking in step312. OS-thread202then executes the I/O function f with a pointers, which points to parameter space203.

Note that before entering the loop above, OS-thread202declares a local variable parameterSpace with a preset amount of memory to implement parameter space203. Note that this local variable stays in tact during: the marshalling process, the function execution, and the unmarshalling process. A pointer to this local variable can easily be tunneled to the L-thread201through a global variable since all setup can occur while there is only one L-thread running. In this way, no other concurrent L-threads can see the global variable.

When the I/O function f returns, L-thread201returns to step302and calls “getParameter” again. This time, in step304, the pointer p is not NULL. Hence, L-thread201calls the function unmarshal(p,out) to unmarshal output parameters from parameter space203into object heap122(step316). Note that this unmarshalling function can involve a memory copy operation. L-thread201then returns (step314).

Instead of using OS-thread202to perform the marshalling and unmarshalling operations, the present invention requires L-thread201to perform these operations. Since the L-threads in virtual machine116are implemented as co-routines in a conceptually single-threaded environment, garbage collection operations on object heap122can be controlled relative to the L-threads. This means that L-thread201does not have to acquire a GC lock before accessing parameters in object heap122.

Because the above-described technique does not allow OS-thread202to access object heap122, OS-thread202does not have to worry about obtaining locks to protect against objects being moved within object heap122by the garbage collection process. Moreover, the present invention is more robust than prior systems because OS-threads do not access object heap122.

Furthermore, since parameter space203is allocated from space associated with OS-thread202, there is less fragmentation of memory within virtual machine116.