Patent Application
20080281887
This invention relates generally to memory management, and more particularly to software applications with garbage collection utilities.
Languages, such as Lisp, Java, C# and Ada, are based on dynamic resource management utilizing a garbage collection system. Garbage collection (GC) takes care of freeing dynamically allocated memory that is no longer referenced. Because the objects in the Java heap are garbage collected, Java programmers don't have to explicitly free allocated memory. Garbage collection has also been implemented in other languages, such as C and C++.
Garbage collection is implemented as a part of a managed runtime platform, such as the Java virtual machine (VM). Restricted embedded devices, such as mobile terminals, need to have an optimized runtime platform, especially in terms of their memory footprint. This means that a simple garbage collection utility is usually implemented in a mobile terminal Java VM.
Java Mobile Device Profile (MIDP) is the most widely adopted application platform in mobile terminals currently. More advanced and feature-rich platforms are being developed and standardized, allowing more advanced and more complex applications to be run on top the Java platforms. Several different Java VM implementations from different vendors are in use. A specific GC algorithm is not standardized in the Java specifications; it is left to the Java VM vendor to decide what kind of GC algorithm or utility to use.
Even though a generic GC utility is sufficient for most applications, some applications would greatly benefit from a more specific or customized GC utility. Applications may have performance characteristics that result in long noticeable garbage collection pauses, which can cause the user perception of the application to degrade. It may be necessary to completely redesign an application because of an unsuitable GC utility on a particular platform, which increases development costs. Further, each application platform implementation may have its own GC utility, which makes it unfeasible to target one GC utility in application design.
Thus there is a need for a GC utility that can better fit the requirements of a particular application.
Certain embodiments of the present invention include a system and method that allows an application to implement its own Garbage Collection (GC) utility that can be designed and tuned for the specific application. The GC utility can be bundled with the application, and can be installed on a platform or virtual machine as necessary along with the application. When the application is activated, the specific GC utility is also activated. Such specific GC utility can provide improvements in performance. The present invention may be used on any type of platform, such as a Java platform, and any type of hardware such as mobile devices.
In certain embodiments of the present invention, a software application can use a GC utility with a suitable and optimized GC algorithm, which can improve performance.
Another advantage is that a platform (such as a Java platform) need not store many GC utilities in order to achieve application adaptation. This saves storage memory, which may be limited, such as with flash memory.
Another advantage of certain embodiments of the present invention is more adaptability to a Java platform and improved performance.
An embodiment of the present invention includes steps of activating an application, determining whether a specific garbage collection (GC) utility is installed for the activated application, and if the specific GC utility is installed, activating the specific GC utility along with the application. These steps may include utilizing the specific GC utility to perform memory garbage collection for the application. An embodiment may include accessing the specific GC utility through a GC invocation API (application program interface), wherein the GC invocation API allows standardized access to any one of a plurality of GC utilities. Further, the specific GC utility may perform memory garbage collection utilizing a memory manager API (application program interface), wherein the memory manager API allows standardized access by any one of a plurality of GC utilities to memory functionality.
The specific GC utility may be designed to perform memory garbage collection efficiently for the application. This may include a feature that the specific GC utility includes information regarding at least one class of objects utilized by the application.
This information may allow the specific GC utility to more efficiently perform GC operations.
An embodiment may include steps of receiving the application for installation, the application including the specific GC utility to be used by the application, and installing the specific GC utility so as to allow the specific GC utility to be used by the application. It may also include a step of providing a pluggable interface, wherein the specific GC utility uses the pluggable GC interface when the specific GC utility is used by the application. If the specific GC utility is not installed an embodiment may activate a basic GC utility available for applications, to perform memory garbage collection for the application. The GC utility may be installed on a Java virtual machine, or any type of platform.
Another embodiment of the present invention includes a first application to be installed on a platform for execution, wherein the platform includes a default GC utility to perform memory garbage collection for applications executing on the platform. The first application includes an indication to indicate to the platform that when the first application is executing on the platform, a specific GC utility, that is different from the default GC utility, should be used to perform memory garbage collection for the first application. The first application and the specific GC utility may be included in an application distribution package, and when the first application is installed on the platform for execution, the specific GC utility is also installed on the platform. The platform may include an application GC selector, the application GC selector responsive to the indication to select the specific GC utility when the first application executes. Such specific GC utility and default GC utility may perform memory garbage collection utilizing a memory manager API, which allows standardized access by any one of a plurality of GC utilities to memory functionality.
An embodiment may be used on any type of device, including a mobile device. It may be utilized on any device or apparatus, including an apparatus with a processor and memory coupled to the processor, wherein instructions stored in the memory or on computer readable medium will implement the embodiment.
In the following description of various illustrative embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown, by way of illustration, various embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope of the present invention.
Embodiments of the present invention provide a platform that allows an application to implement its own Garbage Collection (GC) utility that can be designed and tuned for the specific application. The GC utility is bundled with the application, which means that the GC utility does not have to be stored permanently and in advance in the Java platform. The GC utility can be removed when the application is removed.
In accordance with one embodiment of the present invention, the platform for the application supports dynamically installable GC utilities. When the application is run, the platform will select the GC utility that was installed with the application to be used with the application.
Such an embodiment is illustrated in
The platform 20 includes a runtime core 21 that uses a GC utility during runtime. The runtime core 21 selects the GC utility for use by an application 28 by querying an application GC selector 24. Alternatively, the application GC selector 24 is not used, and an application 28 is responsible for selecting what GC utility is to be used.
The platform 20 also includes an application manager 26 that is able to detect applications having a GC utility, install such GC utility on platform 20 (for example, during application installation), and remove GC utilities from the platform 20 (for example, during application removal
During installation of the application 28 on the platform 20, the specific GC utility 32 is also installed on the platform 20.
According to this embodiment, the selected GC utility 22, 32 typically helps implement the certain features in the GC Invocation API 36. These features may include:
Other features can also be provided depending on the platform. Typically both the GC Invocation API 36 and the Memory Manager API 38 are platform-specific and depend on the Java VM implementation.
As an example for this embodiment, the Application 28 may request a new object by sending a request to create a new object to the VM Core 34, as shown by arrow 29. The VM Core 35 may check with the Application GC Selector 24, to determine if the application 28 has an application-specific GC utility. This result may be cached to avoid multiple calls to the application GC selector 24 for the same application. The VM core 34 may then issue an allocObject call to the specific GC utility 35, using the GC invocation API 22. The specific GC utility may perform some internal bookkeeping for the allocated object or memory (for example, performing reference counting for the object, or determining where in memory to allocate the object), and then make requests to the common memory manager as necessary to allocate memory for the new object.
The common operations that may be offered by the platform 30 in the Memory Manager API 38 for this embodiment are:
According to this embodiment, the memory need not be contiguous for the GC utility 32. The Memory Manager API 38 can manage the memory appropriately so the GC utility 32 does not need to be concerned with non-contiguous memory segments for the application 28. If it would be helpful (e.g. due to performance reasons) the lower level memory architecture can be exposed to GC utility 32 by the Memory Manager API 38.
An application 28 may be installed on the platform 20. The application 28 may be any type of software application, program, utility, or other system that runs on the platform 20. In this embodiment the application 28 includes its specific GC utility 32. In one embodiment, the GC utility 32 is a separate file in the application distribution package. A GC utility 32 may typically be implemented in the same language as the platform 20. In case of Symbian, for example, the Java VM is implemented in C++ using several DLLs for various VM features. The default GC implementation 22 is in one of DLLs. The pluggable GC utility 32 that comes with the application 28 can be a DLL file that is installed into the platform 20.
The GC utility 32 may be designed and optimized for the application 28. For example, many mobile applications 28 (such as games) suffer from unsuitable GC utilities, with problems including visible UI (User Interface) distortions because of GC pauses. If application 28 is a real time game that can not tolerate long pauses for garbage collection, the GC utility 32 may include an ephemeral (generational) algorithm with memory partitioned into multiple small spaces, and with very quick copy operations to clean out the small memory spaces used by the application 28. Alternatively, if the application 28 is a game that can tolerate long pauses (such as when waiting for a user to provide input), the GC utility 32 may include larger memory partitions that can have the live objects copied out in a longer (but less frequent) garbage collection.
Another GC utility 32 may be tuned to the application 28 in that the application 28 is able to re-create memory objects very quickly, so the GC utility 32 can free up memory by simply reclaiming all memory objects in a very fast operation, and then the application 28 may re-create memory objects as necessary.
Still another GC utility 32 may work to maintain a pool of objects of a certain type that are reused by the application 20 instead of being de-allocated from memory when the object is no longer referenced. The GC utility may maintain a list of such objects that are no longer used, and when a call is received for a new object of that type, the GC utility 32 will return an existing object from the list and remove the object from that list. The maximum number of objects stored on the list may be tuned statically or dynamically to achieve an efficient balance of memory use and processing overhead.
An important issue in GC algorithms is the lifetime of the objects. Default GC algorithms and utilities rely on application average characteristics regarding what is the lifetime of an object. Most modern generational GC algorithms rely on two principles:
Most newly created objects die soon.
Old objects tend to live forever.
If an object survives several GC rounds, it is moved to “old space” that is rarely collected (and this is very expensive). If, for example, application characteristics are such that it creates a lot of mid-length lifetime objects (for this example, we refer to them as instances of class A), the default approach creates long GC delays. Objects are moved to old space, but then need to be collected shortly thereafter. A suitable GC utility for this application would be one that identifies object instances of class A (using Class* getObjectClass (Object *obj)) during the GC and treats those differently than other objects. Depending on the GC utility implementation, such Class A objects can for example not get moved to the old space. Thus various embodiments of the invention allow tailoring of GC algorithms and utilities for specific object types. Knowledge of the lifetime characteristics of certain object type can thus be used to improve the GC performance.
As another example, generational GC algorithms typically rely on a memory heap structure that includes “new space” and “old space” area. The size of these areas is fixed, which means that when one area fills up, the application execution ends with an “out of memory error” even though there may be space in the other area. An application may wish to optimize for memory usage (perhaps at the cost of performance) and provide a plug-in GC utility that is based on just one memory area (for example a “mark and sweep algorithm” or a “compact in place” algorithm, etc.). All memory in this area can be fully utilized by the application. This way the application is able to execute on a platform that would have too little memory using the default generational GC algorithm and related heap structure.
Application object lifetime characteristics are typically not associated to any particular application type. Even simple applications can create a lot of objects and their characteristics can differ from the average. Thus, the present invention provides an ability to customize the GC utility for a specific application.
The GC utility 32 may be implemented in any language, including in native C/C++ language, even though the application 28 may be implemented in e.g. Java. The GC utility 32 may be e.g. a DLL (dynamic link library).
In another embodiment, in addition to the two APIs previously described (the GC invocation API 36 and the Memory Manager API 38,
If the application is uninstalled from the platform, the GC utility may be uninstalled with the application. However, if the GC utility is used by more than one application, the platform may skip removing the GC utility. Further, some implementations may decide to delay uninstallation of the GC utility until storage memory is about to run out. If a particular GC utility is already installed when an application with the same GC utility is installed, it is then possible to skip installation of the particular GC utility.
In an alternative invention implementation, the GC utility that comes with the application may be in a form other than binary code. For example the GC utility may be a set of parameters to tune or optimize a standard GC utility. Alternatively it may be a script or formal description that the platform may interpret and implement. In this case the platform may include a particular parsing component that is able to handle the GC algorithm description. The platform GC system may be completely adaptive, allowing the GC algorithm description to largely define the behaviour of the GC
An embodiment of the present invention can work on a platform with multiple applications running in parallel. Typically all applications share the same heap that is managed by one GC utility. A problem may occur if parallel applications use different GC algorithms. This embodiment may separate heap areas for applications that define their own GC utility. Alternatively, if an application defines its own GC utility, then that GC utility is used for all running applications.
A system for implementing an embodiment of the present invention is shown in
As shown in
Short-range radio transmitter/receiver 62 is connected to processor 52 and enables communication via short-range radio communications, such as communications via a BLUETOOTH™ link or communications with radio frequency identification (RFID) tags. GPS receiver 64 receives GPS transmissions and communicates with processor 52 to enable the processor to determine current location information for mobile device 50. Mobile device 50 may also take advantage of other positioning mechanisms, such as positioning methods based on communication signals between the mobile device and base stations (e.g., triangulation methods) and proximity based methods (e.g., communication with a BLUETOOTH proximity sensor). Other sensors may be included in mobile device 50, such as accelerometers, cameras, thermometers, microphones, compass, etc. that can provide context information for the mobile device. For instance, accelerometers or a compass within mobile device 50 may provide information in concert with GPS receiver 64 to assist with providing real-time map updates to the user based on user movements along a route. Overall, mobile device 50 is generally a mobile computing device, such as a handheld personal computer, a mobile communication device, and a mobile terminal, that may include a variety of internal components, communication hardware and software, attachments, and the like.
In accordance with instructions in memory 56, the processor performs steps for providing a platform to allow applications to run, such as on a virtual machine. When the application 66 is run, it is typically partially or fully loaded into the memory 56. The application 66 typically uses some allocated memory 68 for its processing. Such memory 68 may be pre-allocated to the application 66 upon activation, or the memory 68 may be provided in varying amounts upon requests from the application 66. For GC purposes, it may be preferable to have a contiguous section of allocated memory 68; however a GC Utility may be optimized to work with non-contiguous memory areas, in accordance with an embodiment of the present invention. A GC utility 70 may be activated with the application 66, the GC utility 70 also having access to the memory 68, in order to perform storage management and reclamation. As previously described, this application specific GC utility 70 can provide a much improved garbage collection, and greatly improve the functioning of both the application 66 and the mobile device 50.
Additionally, the methods and features recited herein may further be implemented through any number of computer readable media that are able to store computer readable instructions. Examples of computer readable media that may be used include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, DVD or other optical disk storage, magnetic cassettes, magnetic tape, magnetic storage and the like.
While illustrative systems and methods as described herein embodying various aspects of the present invention are shown, it will be understood by those skilled in the art, that the invention is not limited to these embodiments. Modifications may be made by those skilled in the art, particularly in light of the foregoing teachings. For example, each of the elements of the aforementioned embodiments may be utilized alone or in combination or subcombination with elements of the other embodiments. It will also be appreciated and understood that modifications may be made without departing from the true spirit and scope of the present invention. The description is thus to be regarded as illustrative instead of restrictive on the present invention.
