Mobile communication device application processing system

A system and method of pre-linking classes for use by one or more applications. The system and method may also be used where the runtime processing is split between a host system and a target system. At the host system at least several classes are loaded and linked. At least one host-linked module is generated from the linked classes. The host-linked module is made available for use by the one or more applications operating on the target system.

BACKGROUND

This invention relates to the field of processing machine runtime environments. In particular, this invention relates to a method of splitting a processing machine runtime between a host system and a target system for conserving resources at the target system.

Currently, the state of the art virtual machine is the Java™ virtual machine (JVM) from Sun Microsystems, Inc. (Sun). At the centre of Sun Microsystems Java™ technology is their Java™ virtual machine code, or byte code, as currently specified by the class file format in chapter 4 of the second edition of The Java™ Virtual Machine Specification by Tim Lindholm and Frank Yellin, Addison-Wesley Pub Co; ISBN: 0201432943.

Class file byte code co-operates with Sun's Java™ Runtime Environment (JRE) on the Solaris™, Win32, Linux™, Mac, and possibly other platforms. Typically, source code written in the Java™ programming language, is compiled into virtual machine byte code respecting the class file format by using a Java™ compiler, such as “javac”, and then executed using the JRE or a compatible runtime environment and processing machine.

In reference toFIG. 1, a layered JRE architecture block diagram illustrates several aspects of the Sun technique. Various mechanisms (100A and100B) provide program software (110A and110B) byte code class files. For instance, a compiler100A compiles software110A into byte code class files. Alternatively, a web browser may use a software “plugin”110B to download software100B byte code class files.

Byte code in a class file usually references several other classes, each of which has a class file. For that reason, standard package120class files are provided as a shared software resource to be re-used by instances of software (110A and110B). The JVM140obtains class files and executes software (110A and110B) and standard package class files120.

Also shown are the various systems130on top of which the JRE142operates. The standard packages in a runtime define a particular runtime platform specified in an application programmer's interface (API).

The Java™ 2 Standard Edition (J2SE) is a Sun reference platform API. They also provide a reference implementation comprising a JRE configured with a set of standard packages running on the JVM. Application developers can write applications in the Java™ programming language referring to the J2SE standard package classes and may expect to have their applications run on J2SE compliant runtime systems. Other platforms exist which are usually defined by comparison to the J2SE. For instance, a superset of J2SE, the Java™ 2 Enterprise Edition (J2EE) adds further features. Of particular interest is a subset of J2SE, the Java™ 2 Micro Edition (J2ME).

Although the J2SE platform may be well suited to operate on systems such as those illustrated by the Solaris™, Win32, Mac, Linux™, and other blocks130ofFIG. 1, J2SE may not be well suited for operating on many devices. For instance, the class files of the standard J2SE packages may presently consume well over 16 Megabytes of disk space, which may exceed the storage capacity of many devices.

To address this problem, Sun introduced the Java™ 2 Micro Edition (J2ME) platform, additional virtual machines, and associated device configurations.

The Connected Limited Device Configuration (CLDC) and K Virtual Machine (KVM) address small consumer devices that you hold in your hand, with 128K to 512K of memory, and when used with the Mobile Information Device Profile (MIDP) may provide an application environment for devices such as cell phones and two-way pagers.

The Connected Device Configuration (CDC) and C Virtual Machine (CVM) address emerging, next-generation consumer devices with 2 MB or more of memory, and when used with the Foundation Profile (FP) may provide an application environment for next-generation consumer devices.

An advantage of J2ME is that when it is used with the aforementioned CLDC or CDC configurations, fewer standard class packages are stored on many devices as compared to J2SE. Therefore J2ME may take up less space on a device at the expense of not supporting all of the features of J2SE.

Although Java™ runtime technology may be available for different systems and devices, and although the J2ME platform addresses the limited storage space problem of devices by removing functionality, J2ME may not be considered an adequate solution since it may not address the efficiency of a device runtime implementation. Thus, there is a need for a runtime that is optimized for a target device (as well as other needs).

In order to better understand the present invention, the following information regarding Java runtime technology is provided. According to Lindholm et al., in section §2.17.1 of the Sun JVM spec: “The Java virtual machine starts execution by invoking the method main of some specified class and passing it a single argument, which is an array of strings. This causes the specified class to be loaded (§2.17.2), linked (§2.17.3) to other types that it uses, and initialized (§2.17.4)”. Therefore by specifying the name of a “main” class when starting the JVM140ofFIG. 1, a class file will be loaded and execution of byte code instructions will begin at the static main entry point of that class file. Furthermore, referenced types, such as classes, used by the “main” class will be linked and initialized. Depending on the use of other classes by the “main” class file, significant runtime resources will be consumed in order to load and link used class files.

Java™ runtime technology requires that the runtime system load and link all required class files each time a “main” class is specified for execution, which may cause the precipitous consumption of resources on a target system such as a device.

A typical Java™ application has at least one “main” class file containing a static main entry point, as well as possibly having several supporting class files.

The following example Java™ program listing is considered next:

The above listing provides source code for two classes, Hello and Bye, each of which can be compiled into class file format in a way which is known to a person skilled in the art, such as by placing the source for each class in a Hello.java file and a Bye.java file and using the command “javac Hello.java Bye.java” to obtain a Hello.class file and Bye.class file.

The Hello class provides a static main entry point and is therefore suitable to be specified as a “main” class when starting the JVM140.

In reference toFIG. 2, the linking technique of the runtime ofFIG. 1is considered in reference to the above example “Hello” program. A plurality of class files200is available to the virtual machine140(ofFIG. 1). Each class file has symbolic information that is used by the virtual machine140to resolve references to other used class files.

Typically, the Hello.class file210A is loaded at220A first as it is specified when starting the JVM140. The JVM140then proceeds to execute byte code instructions at the main entry point of the loaded class220A. Since the Hello class220A uses several standard package classes, the class files for the used classes will be loaded and linked to the Hello class220A. The Object.class file210B will be loaded at220B and linked230B to the210A Hello class. Similarly, the String.class file210C, System.class file210D, and other class files210used by the Hello class are loaded at220C,220D,220and linked at230C,230D, and230. The Hello class also uses the Bye class (a supporting class which is not a standard package class) so the Bye.class file210E will be loaded at220E and linked at230E.

Although not expressly shown in the drawings, each time a class file210is loaded at220and linked at230, any class files the loaded class220uses might also be loaded and linked. For instance, in the case of the loaded supporting Bye class220E, it uses many of the same classes as the Hello class210A. Depending on when the Bye class220E is loaded and linked230E, the Bye class220E may not have to load the class files210that are common with classes also used and loaded by the Hello class. However, all classes used by Bye220A will ultimately have to be linked to Bye as well for Hello to be able to use the supporting Bye class. The situation is similar with standard package classes.

Traditional class file210loading (at220) and linking (at230) consume significant runtime resources and may slow down the execution of a “main” program220A when loading and linking of class files is triggered by the specification of a command to execute a program, as will be discussed further next in reference toFIGS. 3A and 3B.

With reference toFIGS. 3A and 3B, a flowchart further illustrating the runtime linking technique ofFIG. 2, particularly illustrating optional late resolution, is discussed. The “main” class is loaded at310from class storage200, such as a hard drive or a network. The class is verified and prepared at315. If late resolution is not used as determined at320, then all used classes are linked and loaded at325. Regardless of whether late resolution is used at320or not, the “main” class is initialized at330.

Instructions from the main entry point are fetched at335. If the fetched instruction does not involve an unresolved reference as determined at340, the fetched instruction is. executed at345. However if the fetched instruction involves an unresolved identifier reference as determined at340, such as a class reference to a class that has not yet been loaded, then if late resolution is not used as determined at350, an exception is thrown in the runtime. If late resolution is used as determined at350, and if the referenced class cannot be loaded at355, an exception is thrown in the runtime. However, if late resolution is used as determined at350, and the referenced class can be loaded, the referenced class is loaded and the reference is resolved at360prior to executing the instruction at345. If there are more instructions to execute as determined at365, then the next instruction is fetched at335, or else the virtual machine ends.

If late resolution were used, then several class files would have been loaded and linked at360during execution of the main program byte code. Alternatively, if late resolution were not used, several class files would have been loaded and linked at325prior to executing the main program byte code, after specifying the “main” class file to the JVM140. In either case, a precipitous consumption of resources for loading and linking may ensue between the time the main program was specified for execution by the JVM140in the runtime and the time when the main program either terminated or threw an exception.

Therefore, even by eliminating late resolution, there is a potential risk for a precipitous consumption of resources for loading and linking class files in execution triggered linking and loading.

SUMMARY

The present invention overcomes the problems noted above as well as others. In accordance with the teachings of the present invention, a system and method are provided for pre-linking classes for use by one or more applications. The system and method may also be used where the runtime processing is split between a host system and a target system. At the host system at least several classes are loaded and linked. At least one host-linked module is generated from the linked. classes. The host-linked module is made available for use by the one or more applications operating on the target system.

The same reference numerals are used in different figures to refer to similar elements.

DETAILED DESCRIPTION

FIG. 4depicts an embodiment of a module-based runtime system. Instead of unlinked class files, a processing machine440executes modules450that include classes that have already been loaded and linked. More specifically, the modules450comprise the information found in closed set loaded and linked class files, thereby optimizing commands, symbolic information, and code size and speed for the target processing machine440. Modules450allow the runtime to re-use the intermediate loading and linking work in multiple executions of main programs, instead of repeating this work at every execution. Modules450provide an alternative to execution triggered loading and linking.

A compiler (or other mechanism)405receives a class file407which include symbolic references409to other classes411. The compiler405processes class files407and411which are in byte code such that the symbolic references409are resolved. The processed class files are provided to the processing machine440as modules450. The processing machine440operates more efficiently on target devices430since typically the module size is substantially smaller than traditional runtime class files, for example, there may be a reduction approximately eight-fold in comparison to Java class file size. Also, module code can be verified once using sanity checks prior to multiple executions, thereby increasing subsequent execution speeds. Modules can be configured to minimize code communication, particularly useful in communication bandwidth-limited devices. Modules450can be configured to minimize code set up and execution time, particularly useful in runtime resource-limited devices. Modules450can be adapted to existing processing machine runtimes while maintaining compatibility with reference APIs, asFIG. 5illustrates.

FIG. 5illustrates an embodiment wherein various mechanisms405A and405B provide software410. A compiler405A compiles software410. Alternatively, other mechanisms405B can be used to download or otherwise obtain software410. Standard class packages420are provided as a shared software resource to be re-used by instances of software410. The processing machine440obtains classes and executes software410using standard class packages420.

Also shown are the various target devices430on top of which the processing machine440operates, such as a mobile device430A, a personal data assistant (PDA)430B, an appliance430C, a thin client430D, or other device430E.

InFIG. 5, modules450have been introduced between the mechanism that provides software410and the processing machine440that executes machine code. The processing machine440however still uses the classes in the provided software410as well as the standard class packages420, except that this is now done through the use of modules450rather than directly using class files. Class files can still be used as the compiler can take both class files and source files on its input and produce modules on its output.

Because of the presence of modules450, the processing machine440need not be a virtual machine nor even know about the class file format, thereby optimizing performance at the target system by eliminating the need to load, link, and resolve class files. Further optimizations are possible if the provided runtime is split between a host system and a target device430, as described in reference toFIG. 6.

FIG. 6illustrates a split embodiment of a module-based runtime system. The class runtime processing is split between a host system530and a target system430. The use of modules allow the runtime to be efficiently split between a host system and target device to optimize runtime efficiency at the target device.

In the host system split runtime, class files (407and411) are host-linked at510into host-linked modules520. The work of closed class file set analysis is offloaded to the host system530. In the target system split runtime, host-linked modules520are communicated at540from the host system530, to be target-linked at550into target-linked modules560. If any additional class resolution is needed on the target system430, then the additionally needed target module identifiers562are target-linked at550with the host-linked modules520to form the target-linked modules560. The processing machine440executes the target-linked modules560.

FIG. 7is a block diagram illustrating another split runtime system. For the host system530, class files410are host-linked at510into host-linked modules520. For this system, the details of host linking will be discussed further in reference toFIGS. 8,9and10below. For the target system430, host-linked modules520are communicated at540from the host system530, to be target-linked550into target-linked modules560. The communication540between host and target may occur over any medium so that the module(s) may be provided to the target, such as through a mobile communications network if the target is a mobile communications device, or through a data signal embodied in a carrier signal. The details of target linking will be discussed further in reference toFIGS. 8,9and11below.

In reference toFIG. 8, a block diagram illustrating the loading of class files, and the split linking into modules, and execution of the split module runtime ofFIGS. 6 and 7is described presently. The work of closed class file set analysis is offloaded into a host system400A. There, class files600are loaded at610and linked into host-linked modules520A and520F. Illustrated are an application module for the example “Hello” module520A comprising the optimized information found in the Hello.class file610A and Bye.class file610E wherein the Hello class is pre-linked to the Bye class. Module520A also has a symbolic reference615to a Library module520F which comprises all of the standard package classes that the Hello and Bye classes use, such as the classes provided by the Object class file610B, String class file610C, System class file610D, and other class files610. The Library module520F could export all public symbols so that many different “main” classes such as Hello can re-use all of the standard class package files. Altematively, the Library module could comprise only those class files used by the Hello and Bye classes, or even all used classes could be included directly in module520A. The latter case would eliminate the need for any symbol resolution on the target system.

When at least one host-linked module (520A and/or520F) is available, it is possible to communicate at540the candidate module620A and620F to the split runtime on the target system400B. Once the candidate modules (620A and602F) are received on the target system, it is target-linked into a target-linked module560A and560F and any module symbolic references615are resolved as shown at630. A main module class can be specified for execution, such as the Hello class640. However, advantageously, each time the main program of the Hello class executes, there is no need to resolve reference650as the target-linking630provides it.

With reference toFIG. 9, a flowchart further illustrating the linking technique ofFIG. 8, depicting a host-linking step and a target-linking step, is described. In the split runtime system on the host, classes600are loaded and host-linked at800into host linked modules520. Then, at least one host-linked module520is sent to the split runtime system on the target.

In the split runtime system on the target, at least one candidate host-linked module620is received at720from the host. The candidate host-linked module620is target-linked at900into a target-linked module560. At least one target-linked module560is executed at730. If a new module is desired as determined at740, the host-linking process800, communications processes (710and720) and target linking process900cycles may ensue. However, if no new modules are desired, then repeated execution at730of target-linked modules can ensue without the overhead of loading and linking.

In reference toFIG. 10, a flowchart further illustrating the host-linking step ofFIG. 9is described. In the split runtime system on the host, host linked modules520exported symbols provide at810foreign module identifiers815. Also, classes600provide at820candidate host classes825. Class references in the candidate host classes825are replaced at830with module references using foreign module identifiers815, thereby providing closed set candidate module classes835. Then, candidate module exported identifiers845are provided at840. The candidate module classes835and exported identifiers845are then verified at850. If verified as determined at860, then the candidate host-linked module is provided at870as a host-linked module520. If not verified as determined at860, an exception is thrown.

In reference toFIG. 11, a flowchart further illustrating the target-linking step ofFIG. 9is described. In the split runtime system on the device, the received candidate module620provides at910candidate module references915. Also, target-linked modules560provides at920target module identifiers925. Next, resolution of module references in the candidate module provides at930a resolved module935. The resolved module935is verified at940, and if the resolved module935is verified successfully as determined at950, then the resolved module935is stored at960with other target-linked modules560. However, if the resolved module935is not verified successfully as determined by950, an exception is thrown.

Having described in detail the preferred embodiments of the present invention, including preferred modes of operation, it is to be understood that this invention and operation could be constructed and carried out with different elements and steps. The embodiments are presented only by way of example and are not meant to limit the scope of the system and method of the present invention, which is defined by the claims.

To illustrate the wide scope of the system and method, the following is provided. Virtual machine code is usually interpreted by software. However, a virtual machine code processor can be implemented in hardware. Adaptation of the system and method to a hardware processing machine runtime is within the scope of the invention. As additional examples of the wide scope of the system and method, the system and method may allow for the optimization of commands, symbolic information, and code through the use of the system's and method's modules. The system and method may allow for a module size that is substantially smaller than traditional runtime class file, for instance by reducing in some cases by eight-fold the module size in comparison to Java class file size without losing functionality. The system and method may provide that module code can be verified using sanity checks once prior to multiple executions.

The system and method may also allow a module to combine only new classes to minimize module storage size and allow for efficient module delivery to communication bandwidth-limited devices. As another example of the wide scope of the system and method, the system and method can combine all required classes to minimize code set up and execution time in resource-limited devices. The system and method may be adapted to existing processing machine runtimes while maintaining compatibility with reference APIs. The system and method may provide that modules can be dynamically linked together while minimizing the number of symbolic references. Still further, the system and method may provide that code in modules can be executed directly from storage on a device, unlike class files that have to be loaded from storage prior to execution.