WO2000046664A2

WO2000046664A2 - Instrumenting streamed classes

Info

Publication number: WO2000046664A2
Application number: PCT/US2000/001079
Authority: WO
Inventors: Justin F. Chapweske; Kevin D. Herrboldt
Original assignee: Cyrus Intersoft, Inc.
Priority date: 1999-02-05
Filing date: 2000-01-18
Publication date: 2000-08-10
Also published as: WO2000046664A3; AU3346400A

Abstract

A system and method for processing streamed elements to be passed to a virtual machine receives the streamed element in an input stream, processes the streamed element, stores the processed streamed element in a buffer, and notifies the virtual machine that the streamed element is available. Examples of streamed elements include, without limitation, classes, archive files and resources. Processing a class may include instrumenting the class with enhanced functionality. A method of instrumenting includes replacing a class reference or other constant in a constant pool of the received class with another reference or constant in accordance with a map array. Processing a resource may include converting the received resource to another format analyzing the resource for particular characteristics. Notification of the availability of a received stream element can be made in response to a request from the virtual machine, if the requested class is available in a cache or buffer.

Description

INSTRUMENTING STREAMED CLASSES

Background of the Invention

1. Field of the Invention

The present invention relates generally to systems and methods for processing data, and more particularly to systems and methods for executing, instrumenting, and otherwise processing program code and data for transmission to a virtual machine.

2. Description of Related Art

The Internet has motivated millions of people worldwide to use computers. Electronic mail ("e-mail"), for example, is a reason that many businesses and individuals first buy a computer or connect their computers to a network. E-mail is typically communicated across the Internet to recipients across town, across the country, or across the globe. As such, the Internet and other means of networking computers have become an important tool in modern business and culture. Other Internet-based tools that have significantly contributed to the use of computers and computer networks include the World Wide Web and related web browsers. Generally, the World Wide Web is comprised of millions of virtual web pages comprised of program code and data. Such web pages are physically stored on a server computer connected to the Internet. To browse a web page, a user generally inputs into the web browser an address (e.g. , a Universal Resource Locator ("URL")) associated with the web page. A server on which the specified web page is located transmits program code and data associated with the web page to the browser computer ("the client"). The web browser includes software modules capable of executing or otherwise processing the program code and data for the web page. Typically, this processing causes a graphical or textual representation of the web page to be displayed on the client monitor.

Between 1994 and 1996, a software technology, now called Java, was developed. Java is a programming language that has close ties to Smalltalk and C++, and its primary purpose was to be a cross-platform, distributed, network- based language. Java provides a complete programming environment that provides basic services (like graphics and networking), allowing application developers to obtain needed services from Java itself, as opposed to the operating system. Normally, programs that need access to graphics, network services and data storage, for example, must use a function call provided as part of the base-level operating system (e.g., MS-DOS or UNIX) installed on the client computer. In contrast, Java provides a built-in run-time entity called a "virtual machine" (or "VM") to provide such basic services. Java is also interpreted, which means that unlike C++ or FORTRAN source code, Java source code does not get compiled directly to machine instructions. Instead, Java's source code gets compiled into an intermediate form called byte- codes. On the development machine, a compiler takes the text strings that make up a Java source code program and translates these strings into Java byte-codes. These byte-codes are platform-independent and, therefore, can be sent to and executed by various client computer platforms. To accomplish this, an interpreter (which is typically part of the web browser) reads each byte-code as it is received at the client computer and translates the byte-codes into the appropriate machine code for execution on the client system. At a server, the byte-codes of a Java program are typically organized into program modules called "classes". Generally, a class is a programming data structure within which a programmer can group an object's data with methods that operate on that data. For example, the data within a window class might include the window's size and position coordinates. Likewise, the methods within the window class might include functions that display, size, and move the window. When a Java program is created, a programmer can define his or her own classes within the Java program, or he or she can reference existing classes from a class library that resides in the system. The server may also store resources, such as audio files, image files and other data. These classes and resources, referred to herein as "streamed elements", are preferably stored at the server and transmitted to the client when a Java program is invoked. The top level of the Java program is referred to as the "main class" and typically includes references to other classes required to establish the functionality of the Java program. These reference classes may also reference additional classes in a class reference hierarchy. Typically, the main class and all reference classes are streamed from a server to a client, where the Java program is executed. At the client, a class loader preferably receives the streamed elements in an input stream and loads them in a cache or buffer until requested by the client's virtual machine.

An important feature in many class loaders is the ability to receive a single archive file that contains many classes, such as a zip file or a Java archive (JAR) file. Archive files have significant advantages over individual class files. For example, loading several classes in a single archive file and streaming that single archive file to a client in a single network connection can be orders of magnitude faster than loading those same classes through individual connections, primarily because establishing multiple connections with the server (one for each transmitted class) is time-consuming. Hence, archive files are often preferred because they can greatly reduce the time required to download a Java program to a client.

Using archive files, however, has some disadvantages also. For example, if the Java program comprises a large number of classes in an archive file, the entire archive file (i.e. all of the streamed elements in the archive file) must be downloaded in a single connection with the server (i.e., a single input stream). Consequently, execution of the Java program is delayed until the entire archive file is downloaded. Even in web browsers in which you can specify multiple archive files for a single Java program, a class loader has no way of knowing which particular archive files contain needed classes, so it must still load all of the referenced archive files at once. Accordingly, it is common that a virtual machine must wait until a class loader has downloaded all necessary classes, and more particularly, all streamed elements contained in an archive, before executing the Java program with such classes and resources. A need exists for reducing the delay introduced by downloading classes and resources required by a Java program.

Another disadvantage to existing web browser systems is that a client typically executes a Java program according to the functionality and resources received from the server. Therefore, the client is typically limited to the functionality originally programmed into the Java program. To provide enhanced functionality to the original Java program, however, an approach referred to as

"instrumenting" may be employed. Instrumenting generally involves modifying a class file to contain, for example, new byte-code instructions in existing methods, new fields, or new methods. A disadvantage of existing instrumenting methods, however, is that existing class loaders download a class into a buffer or cache before modifying the class. When the streamed class is included in an archive, the class loader typically must wait until the entire archive is downloaded before instrumenting occurs. This approach introduces undesirable delay in the instrumenting process and requires excessive resources. Consequently, a need exists for a more efficient instrumenting system and method. Summary of the Invention

Additional needs may be met by embodiments of the present invention. Advantages and novel features are set forth in the description which follows and will become apparent to those skilled in the art when taken in conjunction with the accompanying drawings. The advantages of the invention may be realized and attained by means of the instrumentalities and accommodations particularly pointed out in the appended claims.

To address the foregoing needs, in accordance with the present invention, a system embodiment for instrumenting a class to be passed to a virtual machine may comprise a map array including a first reference and a second reference. The first reference is mapped to the second reference. A class processor has access to the map array modifies the class in accordance with the map array. A buffer coupled to the class processor stores the modified class concurrent to passage of the modified class to the virtual machine. The present invention may also comprise a system for processing a streamed element to be passed to a virtual machine. A processor processes the streamed element as the streamed element is received. A buffer stores the processed streamed element. A notification module responsive to a request for the streamed element from the virtual machine notifies the virtual machine when the streamed element is available.

The present invention may also comprise a method for processing a streamed element to be passed to a virtual machine. In this method, a streamed element is received into a first processor via an input stream. The streamed element is modified as the first processor receives the streamed element. The modified streamed element is stored the streamed element into a buffer.

The present invention may also comprise a program product for processing a streamed element to be passed to a virtual machine. The program product comprises instructions for receiving the streamed element into a first processor via an input stream. The streamed element is modified as the first processor receives the streamed element. The modified streamed element is stored into a buffer.

Brief Description of the Drawings

Figure 1 depicts a general purpose computer that implements the logical operations of an embodiment of the present invention. Figure 2 depicts an embodiment of a class loader system in accordance with the present invention.

Figure 3 depicts a detailed diagram of a class loader system in accordance with the present invention. Figure 4 depicts an exemplary class streamed in from a server in accordance with the present invention.

Figure 5 depicts an exemplary map array in accordance with the present invention.

Figure 6 depicts an exemplary class map array in accordance with the present invention.

Figure 7 depicts a flowchart for operations of processing a streamed element to be passed through a virtual machine in accordance with the present invention.

Figure 8 depicts the flowchart of operations for processing virtual machine requests for a streamed element in accordance with the present invention. Figure 9 depicts a flowchart of operations for servicing virtual machine requests as an archive file is being received in an input stream in accordance with the present invention.

Detailed Description of the Preferred Embodiment

Figure 1 depicts a general purpose computer capable of executing a program product embodiment of the present invention. One operating environment in which the present invention is potentially useful encompasses the general purpose computer. In such a system, data and program files may be input to the computer, which reads the files and executes the programs therein. Some of the elements of a general purpose computer are shown in Figure 1 wherein a processor 101 is shown having an input/output (I/O) section 102, a Central Processing Unit (CPU) 103, and a memory section 104. The present invention is optionally implemented in software devices loaded in memory 104 and/or stored on a configured CD-ROM 108 or storage unit 109 thereby transforming the computer system in Figure 1 to a special purpose machine for implementing the present invention. The I/O section 102 is connected to keyboard 105, display unit 106, disk storage unit 109, and disk drive unit 107. Generally, in contemporary systems, the disk drive unit 107 is a CD-ROM driver unit capable of reading the CD-ROM medium 108, which typically contains programs 110 and data. Computer program products containing mechanisms to effectuate the systems and methods in accordance with the present invention may reside in the memory section 104, on a disk storage unit 109, or on the CD-ROM medium 108 of such a system. Alternatively, disk drive unit 107 may be replaced or supplemented by a floppy drive unit, a tape drive unit, or other storage medium drive unit. The network adapter 111 is capable of connecting the computer system to a network via the network link 112. Examples of such systems include SPARC systems offered by Sun Microsystems, Inc., personal computers offered by IBM Corporation and by other manufacturers of IBM-compatible personal computers, and other systems running a UNIX-based or other operating system. In accordance with the present invention, software instructions directed toward loading classes may be executed by CPU 103, and mapping arrays and class and resource data may be stored on disk storage unit 109, disk drive unit 107 or other storage medium units coupled to the system.

Figure 2 depicts an embodiment of a class loader system in accordance with the present invention. The server 200 is preferably a networked file server or application server coupled to the computer network 202, such as an extranet, an intranet or the Internet. Generally, such a computer network supports TCP/IP networking. A client system 204 is also coupled to the computer network 202. Among other components, client system 204 includes the class loader 206 and the virtual machine 208. A local device 210 and network device 212 are also coupled to the client system 204. The local device 210 may be internal or external to the client system 204 and may include, for example, a storage medium or a peripheral. In contrast, the network device 212 represents a device coupled to the client system 204 by way of the computer network 216, which may include, for example, an intranet, an extranet, the Internet, or another type of local area and wide area network. The network device 212 may include, for example, a network server, a networked storage medium, a network peripheral, and other network devices.

The class loader 206 is a mechanism by which files containing Java byte- codes are read into the Java virtual machine 208 and converted into class definitions. The operation of Java programs depends on the class loader, which also works in conjunction with the system's security manager and access controller to provide most of the protection associated with a Java system. As discussed in Chapter 3 of "Java Security" by Scott Oaks (1998), when a Java virtual machine requires access to a particular class, it is the class loader's responsibility to provide the class. Typically, a class loader is passed a fully qualified class name, and it is expected to return the class object that represents the requested class. If the class does not reference a system class object (i.e., already accessible by the virtual machine), the class loader is responsible for loading the class bytes-codes from another source (e.g., from the network). According to the Java specification, a class loader is required to cache the classes that it has previously loaded, so that when it is asked to load a particular class, it is not supposed to re-read the class file from the other source. The caching of previously loaded class may be implemented by the class loader, by the virtual machine, or by other means; however, the base ClassLoader class (as provided in the Java Development Kit 1.1 and greater) now performs this caching automatically: A class is put into the cache of the ClassLoader in the defineClass method and may be retrieved from the cache with the findLoadedClass method.

Generally, a class object is a variable that has a class type, which programmers often refer to as an instance of the class. Java programs define objects in terms of a class, which defines the data that the class object will store and the functions (or methods) that operate on that data. When a programmer creates a program, he or she writes instructions that work with different things, such as variables or files. Typically, such things are represented as class objects, and the Java program operates on the objects to achieve a desired functionality. For example, given a file class object, a program might perform such operations a reading, writing, or printing the file class object.

The caching functionality relates directly to the loading of a Java archive file by the class loader because the archived files are typically loaded in bulk and stored into the cache or buffer 214. Once the classes in the archive file are stored in the buffer 214, the virtual machine can ask for a cached class, and the class loader can return the corresponding class object based on the cached class, rather than waiting for the class loader to re-read the class from the server.

In an exemplary embodiment of the present invention, the class loader 206 modifies loaded classes as they stream into the client system 204 from the server 200 and stores the instrumented classes in the buffer 214. As discussed with regard to Figures 3 and 4, significant advantage exists in instrumenting the streaming classes as they are received and before storing them in the buffer 214.

In another exemplary embodiment of the present invention, the class loader 206 processes requests from the virtual machine as the class elements of an archive file are streaming into class loader 206. Consequently, if the virtual machine 208 requests class A from the class loader 206, and class A has already been loaded into the buffer 214, the class loader 206 transmits the class object corresponding to the cached class A to the virtual machine 208. Alternatively, if class A is not already loaded in the buffer 214, the class loader records the name of the requested class in a pending request queue and continues processing classes in the archive file as they stream. Thereafter, when a class recorded in the pending request queue is received by the class loader 206, the class is preferably stored in the buffer 214 as other classes continue to stream into the class loader 206, and concurrently, the corresponding class object is preferably passed to the virtual machine 208. In accordance with the present invention, "concurrently" does not require "simultaneous" storage of the class and passage of the class object. As such, the virtual machine 208 can execute the Java program using the requested class A object without waiting until the entire archive file to be loaded by the ClassLoader 206 from the server 200.

Figure 3 depicts a detailed diagram of a class loader system in accordance with the present invention. The class loader 303 preferably includes a redirector 302 and at least one processor. The illustrated class loader system includes a class processor (i.e., an instrumenter), a resource processor 310 for graphics data and a resource processor 312 for video data. In addition, resource processors may exist for other resources, such as audio data, or for specific resource formats, such as JPG, .GIF, .WAV, and .AVI files. Generally, streamed elements (e.g., streamed element 301) are received by the class loader 303 via link 300 from an application server or other source.

The redirector 302 receives the streamed elements and directs them in an input stream to appropriate processors in accordance with their associated types. In an embodiment of the present invention, the redirector 302 determines the type of the streamed element by evaluating a suffix on the streamed element file (i.e., in this embodiment, the type of the streamed element file is a preinformed criterion). For example, a streamed element having a ".class" suffix is redirected to class processor 308. In contrast, streamed elements having a "JPG" suffix are redirected to the resource processor 310, and streamed elements having a ".AVI" suffix are redirected to the resource processor 312. This redirection supports multiple processors for processing multiple types of streamed elements in a single class loader.

The class processor 308 preferably instruments the received classes (e.g., class 343) as they are received. A key to understanding an instrumenting process is the format of the received class file 343. According to the Java Virtual Machine Specification, written by Tim Lindholm and Frank Yellin and published by Addison- Wesley, Inc. (1997), specifically incorporated herein by reference for all that it discloses and teaches, a class file is described in Chapter 4 as containing a single ClassFile structure:

ClassFile { u4 magic; u2 minor version; u2 major version; u2 constant_pool_count; cp info constant__pool [constant_pool_count- 1 ] ; u2 access flags; u2 this_class; u2 superclass; u2 interfaces_count; u2 interfaces[interfaces_count] ; u2 fields count field info fields [fields_count] ; u2 methods_count; method info methods [methods_count] ; u2 attributes_count; attribute_info attributes [attributes_count] ;

}

The labels "u2" and "u4" identify the type of the component fields (such as

"magic" and "minor_version"). In accordance with The Java Virtual Machine Specification, the type "u2" is a 16-bit unsigned integer value, and the type "u4" is a 32-bit unsigned integer, value. The other labels, such as "cp_info", represent component field types that are defined elsewhere in the Java program. The constant _pool array is an array of variable-length structures representing various string constants, class names, field names, and other constants that are referred to within the ClassFile structure and its substructures. Each of the constant_pool array entries at indices 1 through constant _pool_count- 7 is a variable length structure whose format is indicated by its first "tag" byte. In an embodiment of the present invention, constants having a CONSTANT_utf8 (string constant) type are processed, although other constant types, such as numeric constants, may also be processed in accordance with the present invention.

A class is received by the class loader in an input stream of bytes. Accordingly, processor 308 can locate specific component fields within the received class using the ClassFile structure as a guide. Preferably, to instrument a class, the processor 308 searches for class name constants in the constant _pool of the input stream for the received class and replaces them with new class name constants, thereby mapping them to new class references. The class references are represented by class name constants in the constant _pool. In Figure 3, a map array 307 and a class map array 304 provide a predetermined mapping from an old class name constant to a new class name constant (see also Figures 5 and 6 for an example of a map array and a class map array). Preferably, the class map array 304 is generated from the map array 307. In an alternate embodiment, only one map array is used to provide the necessary mapping of class name constant. Furthermore, the generator module 350 can dynamically generate or modify the map array in accordance with a predetermined criterion. For example, a class processor can instrument class differently depending on when (e.g., time of day, day of month, etc.) the Java program is downloaded. Alternatively, the criterion can be based on which server or client is involved in the download, which user is logged into the server or client, or the relative loads or other characteristics of the server or associated systems coupled to the server.

In an embodiment of the present invention, the processor 308 reads the first constant value in the constant _pool of the received class and searches for a match with a constant in the "Old Constant" column of the class map array 304. If a match is found, the constant value is replaced with the corresponding (i.e., mapped) constant in the "New Constant" column of the class map array 304 (or map array 307). As a result of the replacement, the instrumented class preferably references new or enhanced functionality as provided by the enhanced class object referenced by the new constant. That is, when the instrumented class object is later executed in the virtual machine 305, processing proceeds to the enhanced class instead of the originally referenced class. Preferably, the enhanced classes referenced by the new constants are already loaded into the virtual machine by the virtual machine's internal class loader (by way of the CLASSPATH variable), although the enhanced class may alternatively be loaded from other local or networked sources.

After the processor 308 instruments the received class 343, the class is defined and preferably passed as a class object into a class buffer or cache 306 for storage until requested by the virtual machine ("VM") 305. The VM request for a class object is preferably received by a notification module 328 in the class loader 303. The VM request is generally based on the references in other classes already loaded into the virtual machine 305. Preferably, the notification module 328 locates the requested class in the class buffer 306, and passes it to the virtual machine 305. In an embodiment of the present invention, the notification module includes a hash table software object that locates the requested class in the buffer

306 and returns it to the virtual machine 305.

The resource processors 310 and 312 function in a manner similar to the class processor 308 in that resources are preferably redirected to the appropriate processor by redirector 302. The resource processors are capable of modifying or otherwise processing the received resource and storing the resulting, processed resource into a resource buffer (such as resource buffer 316) for transmission to the virtual machine 305. Examples of such processing may include without modifying and analyzing the streamed element or triggering another process based on receipt of said streamed element. Multiple resource processors, such as processors 310 and 312, can utilize separate or combined resource buffers to store modified resources. As with the class requests from the virtual machine to the notification module 326, notification modules 326 and 324 handle requests for resources for processors 310 and 312, respectively. Alternatively, notification functionality for multiple or all processors may be performed by a single notification module.

In an embodiment of the present invention, a graphics file 345 is received by the resource processor 310, which for example performs image processing (e.g., brightening light tones) or converts the image into a different graphics format (e.g., JPG to GIF format), and a video file 347 is received by resource processor 312, which for example performs image processing (e.g., cutting the frame rate or brightening light tones) or converts the image into a different video format (e.g., AVI to MOV format). The modified resource is then stored in a resource buffer, such as the resource buffer 316.

Class and resource processing can provide content filtering. For example, offensive language text can be located within classes and replaced with inoffensive language or flagged to a parent, teacher, or system administrator. In a similar manner, resources can be monitored to filter offensive content. For example, image resources can be scanned for specific signatures or particular color distributions or patterns. Identified resources can be deleted or replaced by other resources, or a signal can be sent to a parent, teacher, or system administrator. Also, class processing can provide encryption capabilities. For example, a generic Java-based email application that lacks encryption capabilities can be instrumented to support encryption as it is streamed from a server on the Internet. Furthermore, software licensing authorization can be instrumented into a Java program as it is streamed from a server on the Internet. Figure 4 depicts an exemplary class 400 streamed in from a server in accordance with the present invention. The initial portion of a ClassFile structure includes fields such as magic, major version, and minor _version, and is represented as the region 402 of the class 400. The region 406 represents the portion of the ClassFile structure including access Jlags through attributes. A processor in accordance with the present invention preferably processes the constant _pool_count and constant _pool fields of the ClassFile structure, as represented by region 404. As shown, the constant _pool is typically only a small portion of the entire class.

The streaming instrumentation of an embodiment of the present invention has performance advantages over a non-streaming implementation, where a single class or archive file is downloaded into a buffer and then instrumented, or instrumented in response to a request from a virtual machine. A significant bottleneck in loading class for use by a virtual machine is the communication of each class over the network. In a streaming instrumentation, it is often possible to start instrumenting a class it streams into the class loader and to finish instrumenting before the entire class has streamed in from the server. Consequently, a streaming instrumentation in accordance with the present invention can often result in a net zero delay in the receipt of each class into the class buffer.

For example, without streaming instrumentation, the class 400 requires 1.0 second to download completely from a network, including 0.1 seconds to download the region 402. An instrumenter in accordance with the present invention, however, can completely instrument the class in 0.6 seconds. Accordingly, there is no net delay introduced by the instrumenter. Other optional implementations are contemplated where an instrumenter can modify other regions of a class (e.g., op codes in methods located in region 406). Such implementations can still take advantage of the streaming instrumentation, although the chances of introducing a net delay in the download process increase as the processing occurs later in the byte- code stream. In contrast, a non-streaming implementation requires the download and instrumenting to be handled sequentially (i.e., downloaded for 1.0 seconds into a class buffer and then instrumented for an additional 0.6 seconds for a total of 1.6 seconds).

Figure 5 depicts an exemplary map array in accordance with the present invention. In the illustrated embodiment, both class name constants and string constants are mapped for replacement. A class name constant has an "L" prefix and a ";" suffix for representing a method signature reference in a class. Using such an array, a processor can select a constant (e.g., a class name constant or a string constant) from the constant pool, search for a match with an element in the "Old Constant" column of the map array, and then replace the located string with the corresponding element in the "New Constant" column of map array. For example, a string constant containing expletives can be replaced with a non-offensive string constant, or an original class name constant can be replaced with a new class name constant to reference a class having enhanced functionality.

Figure 6 depicts an exemplary class map array in accordance with the present invention. In an embodiment of the present invention, the rows of the map array of Figure 5 are filtered into a class map array to include only class name constants. Non-class name constants (such as string constants) are reflected as empty rows in the map array. Furthermore, the "L" prefix and the ";" suffix of each class name are stripped to represent a parent class name constant. In an embodiment of the present invention, each string constant in the constant _pool of a received ClassFile structure is evaluated against the "Old Constant" entries of one or both of the map arrays of Figures 5 and 6.

Figure 7 depicts a flowchart for a method of processing a streamed element to be passed through a virtual machine in accordance with the present invention. Operation 700 maps old references to new references in a map array, such as one or both of the examples shown in Figures 5 and 6. Operation 702 receives a streamed element, preferably a class, a resource or an archive file, via a network. Operation 704 passes the streamed element for processing according to its type as the streamed element is received. Processing proceeds to operation 706 if the streamed element is of type "resource". Examples of type "resource" can include without limitation JPG, .GIF, .AVI, and .MOV files. Processing proceeds to operation 712 if the streamed element is of type "class". Other redirections according to type or content are contemplated within the scope of the present invention.

Operation 706 processes the streamed class according to program code accessible by the resource processor. For example, a resource processor can include program code to convert a JPG file into a .GIF file. In operation 708, the processed stream element (e.g., the newly converted .GIF file) is stored in a resource buffer. In operation 710, the class loader notifies the virtual machine that the processed streamed element is available, preferably in response to a request for the streamed element by the virtual machine. Operation 712 locates a constant in the constant pool of the class being received by the class processor that matches an old constant in the map array. In operation 714, the old constant in the constant pool is replaced with the corresponding new constant from the map array as the class is received. Alternatively, operation 714 can modify other portions of the class, including changing op codes in methods, adding new methods, etc. Preferably, all necessary changes in the constant _pool or in any other portion of the class are completed before the class is entirely streamed into the class loader. In operation 716, the modified class is stored in a buffer. Operation 718 notifies the virtual machine that a class is available, in response to a request the class from the virtual machine. Operation 718 may be performed relative to a class already stored in the buffer when the request is made, or alternatively, if the class is not yet available, operation 718 waits until the class is received by the class loader. As discussed with regard to Figures 8 and 9, if operation 718 waits, the pending request is placed in a pending request queue until the class is received and made available to the virtual machine.

Figure 8 depicts the flowchart of operations for processing virtual machine requests for a streamed element in accordance with the present invention. Operation 800 receives a virtual machine request for a streamed element (e.g., a class or a resource) from a virtual machine. Operation 802 attempts to locate the requested streamed element in a buffer (e.g., a class buffer or a resource buffer). It is possible that the requested streamed element has not yet been stored in a buffer. For example, if the class loader is downloading an archive file containing multiple classes, the virtual machine may request a class in the archive that is not yet streamed into the class loader. Therefore, the requested class is not yet available for passage to the virtual machine.

In operation 804, it is determined whether the requested streamed element is available in the buffer. If the requested streamed element is available in the buffer, operation 810 notifies the virtual machine that the requested streamed element is available and operation 812 passes the requested streamed element to the virtual machine. Alternatively, if the requested streamed element is not available in the buffer, operation 806 puts the virtual machine request for the class in a pending request queue. In operation 808, the thread handling the virtual machine request waits until the requested streamed element is available in the buffer. Processing then proceeds to operation 810 where the virtual machine is notified that the requested streamed element is available. Alternatively, operation 808 monitors the streamed elements received by the class loader as they are received, and notifies the virtual machine that the requested streamed element is available. This alternative approach preferably avoids repeatedly searching the class buffer for requested classes in the pending request queue.

Figure 9 depicts a flowchart of a method for servicing virtual machine requests as an archive file is being received in an input stream in accordance with the present invention. Operation 900 receives a streamed element from an archive stream, such as a JAR file or a zip file. In operation 902, the streamed element is processed as it is received. That is, for example, a class is instrumented, or a graphics resource is converted to a different format. In operation 904, the processed streamed element is stored in a buffer. Decision operation 906 determines whether the streamed element is identified in the pending request queue. If the streamed element is identified in the pending request queue, operation 908 notifies the virtual machine that the streamed element is available. Decision block 910 determines whether more streamed elements are streaming from the archive stream. If so, processing returns to operation 900 to receive the next streamed element from the archive stream. Otherwise, processing proceeds to block 912 to wait for further streamed elements or virtual machine requests. While the method disclosed herein has been described and shown with reference to particular operations performed in a particular order, it will be understood that these operations may be combined, subdivided, or reordered to form an equivalent method without departing from the teachings of the present invention. Accordingly, unless specifically indicated herein, the order in grouping of the operations is not limitations of the present invention.

The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.

Claims

WE CLAIM:

1. A system for instrumenting a class to be passed to a virtual machine, said system comprising: a map array including a first reference and a second reference, said first reference being mapped to said second reference; i a class processor having access to said map array for modifying said class in accordance with said map array; and a buffer responsive to said class processor for storing said modified class concurrent to passage of said modified class to said virtual machine.

2. The system of claim 1 wherein said first reference indicates an old class referenced in said class, said second reference indicates a new class, and said processor is configured to modify said class to reference said new class.

3. The system of claim 1 further comprising an input stream for passing said class to said class processor.

4. The system of claim 3 further comprising: a redirector for receiving said class via said input stream and for directing said input stream to said class processor in accordance with a preinformed criterion.

5. The system of claim 1 wherein said first reference matches a first constant string in a constant pool of said class.

6. The system of claim 1 wherein said second reference includes a second constant string that said processor replaces for said first constant string in said constant pool of said class.

7. The system of claim 1 further comprising: a notification module responsive to a request for said class from said virtual machine for notifying said virtual machine when said class is available.

8. The system of claim 1 further comprising a generator module that generates said map array in accordance with a predetermined criterion.

9. The system of claim 8 wherein said predetermined criterion is based on a time schedule.

10. The system of claim 8 wherein said predetermined criterion is based on utilization load of a server coupled to said system.

11. The system of claim 8 wherein said predetermined criterion is based on a characteristic associated with a computer executing said virtual machine.

12. The system of claim 8 wherein said predetermined criterion is based on a characteristic of a computer providing said class to said system.

13. A system for processing a streamed element to be passed to a virtual machine, said system comprising: a processor for processing said streamed element as said streamed element is received; a buffer that stores said processed streamed element; and a notification module responsive to a request for said streamed element from said virtual machine for notifying said virtual machine when said streamed element is available.

14. The system of claim 13 further comprising a pending request queue for storing said request from said virtual machine.

15. A method for processing a streamed element to be passed to a virtual machine, said method comprising: receiving said streamed element into a first processor via an input stream; processing said streamed element as said first processor receives said streamed element to provide a processed streamed element; and storing said processed streamed element into a buffer concurrent with passage of said processed streamed element to said virtual machine.

16. The method of claim 15 further comprising: searching said buffer for said processed streamed element, responsive to a request from said virtual machine for said processed streamed element; and notifying said virtual machine that said processed streamed element is stored in said buffer, if said processed streamed element is stored in said buffer.

17. The method of claim 15 further comprising: storing a request for said processed streamed element in a pending request queue; and notifying said virtual machine that said processed streamed element is available, if said processed streamed element is received after said request is stored in said pending request queue.

18. The method of claim 15 further comprising: redirecting said input stream between said first processor and a second processor in accordance with a type associated with said streamed element.

19. The method of claim 15 wherein said streamed element includes a class.

20. The method of claim 19 wherein the processing operation comprises: mapping a first reference to a second reference in a map array; locating said first reference in said class; and replacing said first reference with said second reference in said class in accordance with said map array.

21. The method of claim 20 wherein the locating operation comprises: locating said first reference in a constant pool of said streamed element.

22. The method of claim 20 wherein the mapping operation comprises generating said map array in accordance with a predetermined criterion.

23. The method of claim 15 wherein said streamed element includes an archive containing a class.

24. The method of claim 15 wherein said streamed element includes a resource.

25. A program storage medium, readable by a computer, tangibly embodying a program of instructions executable by said computer for processing a streamed element to be passed to a virtual machine, the program comprising instructions for: receiving said streamed element into a first processor via an input stream; processing said streamed element as said first processor receives said streamed element to provide a processed streamed element; and storing said processed streamed element into a buffer concurrent with passage of said processed streamed element to said virtual machine.

26. The program storage medium of claim 25 further comprising instructions for: searching said buffer for said processed streamed element, responsive to a request from said virtual machine for said processed streamed element; and notifying said virtual machine that said processed streamed element is stored in said buffer, if said processed streamed element is stored in said buffer.

27. The program storage medium of claim 25 further comprising instructions for: storing a request for said processed streamed element in a pending request queue; and notifying said virtual machine that said processed streamed element is available, if said processed streamed element is received after said request is stored in said pending request queue.

28. The program storage medium of claim 25 further comprising instructions for: redirecting said input stream between said first processor and a second processor in accordance with a type associated with said streamed element.

29. The program storage medium of claim 25 wherein said streamed element includes a class.

30. The program storage medium of claim 29 wherein the instructions for processing comprise instructions for: mapping a first reference to a second reference in a map array; locating said first reference in said class; and replacing said first reference with said second reference in said class in accordance with said map array.

31. The program storage medium of claim 30 wherein the instructions for locating comprise instructions for locating said first reference in a constant pool of said streamed element.

32. The program storage medium of claim 30 wherein the instructions for mapping comprise instructions for generating said map array in accordance with a predetermined criterion.

33. The program storage medium of claim 25 wherein said streamed element includes an archive containing a class.

34. The program storage medium of claim 25 wherein said streamed element includes a resource.