Method and appartus for improved object allocation based on life-expectancy in a Garbage Collected run-time
Original Publication Date: 2009-May-13
Included in the Prior Art Database: 2009-May-13
In a virtual machine environment like the Java Virtual Machine (JVM), garbage collector (GC) subsystem is responsible for object allocation and garbage collection. The state of the art GC algorithm used by most of the Java implementations is Generational GC. A typical generational GC system has the following salient features for garbage collection and heap management: - This algorithm works on the principle that most allocated objects die young. - Every object has an age associated with it. For instance, the age of an object refers to the number of garbage collection cycles during which it has survived . - The heap memory is divided into multiple segments that are termed generations. Each generation is meant to hold objects that fall within the defined age range for that generation. - Every object initially gets allocated onto the generation that is meant to hold the young objects. - When an object requires to be allocated in a particular generation and the available memory in that generation gets exhausted, a garbage collection cycle is triggered in that generation. - During the garbage collection cycle, the survival count of each live object is incremented. - The objects that have a survival count of greater than a threshold value get promoted/moved to the old generation. - Similarly, a garbage collection cycle is triggered in the older generation area when it gets exhausted. - The rationale behind having different generations is, younger generation has more garbage content and older generation has lesser garbage content. This difference allows for applying different algorithms (Copy Collection which works better in a 'more garbage to be cleaned' scenario, Mark and Sweep Collection which works better in a 'less garbage to be cleaned') on different generations. Although the method described above performs optimally in most cases, to handle the long lived objects it has to incur the following costs: - Do a book keeping activity that will keep updating the age of the object. - Move the object to the next generation when it crosses a predefined age. - Update all the references pointing to that object with the new location to which the object was moved to. Developers/Architects are mostly aware of the life expectancy of various pieces of software components developed by them. For instance, a TimerTask that updates the time on the main window of a Java based UI application, is going to live throughout the lifetime of the application and the developer of the UI application certainly knows this. This implies, that the TimerTask is never going to be Garbage Collected. But, the present garbage collectors still spend effort to handle this TimerTask (as they do not know the life expectancy of the TimerTask). Currently, there are no methods by which developers can communicate about the best possible generation where the object can be allocated directly to minimize/avoid movement of objects across generations. In such cases, in order to improve the performance of the application by reducing the amount of time spent during garbage collection, the developer will desire to have finer control over deciding the target area for object allocation. This publication provides a method for developers to pass information about the life expectancy of objects during the development time.
Method and appartus for improved object allocation based on life -expectancy in a Garbage Collected run-time
Ajith Ramanath, Shirish Kuncolienkar, Apurva Sinha1, Anandha S Srinivasan, Manish Gupta, Prashanth K Nageshappa
A method of passing information to the garbage collector via source code constructs is proposed. Proposed method will achieve the following:
Ability to add information on the life expectancy of components embedded in the source
code during the development phase of the product
Ability to make the information on the life expectancy available to the run time (Garbage
Ability to be backward compatible. That is, the GC can honor or ignore the information
passed on to it. This way, the proposed method is backward compatible which is very
important for any popular development platform like Java or C#.
For instance, it is possible to add new language constructs (say, new
would help the developers looking at existing code at a later date
A language that requires a virtual run-time, like Java™,
using which they can associate meta-data with the source code for internal book-keeping. Comments and annotations are some such possible ways by which a developer can achieve the same.
In the current disclosure, we propose to extend the usability of annotations by which the virtual machine executing the binary application code can pick up specific metadata as hints during object allocations.
We propose to divide the objects into four broad categories:
Method local objects (objects that are local to a method and do not escape).
Young objects (objects that the programmer does not expect to live longer).
Mature objects (objects that live substantially longer than others).
Permanent objects (objects that will be live for entire lifetime of the virtual machine).
Consider the source code snippet of a method implemented in Java™ in
1 . The code shows three objects being created and comments in the code indicate the life expectancy of each of them.
_ will live as long as the application lives). But such solution will not be backward compatible.
Ability for IDE track the life-expectancy of Objects in source code (while displaying) that
type construct to Java - and that means, that
provides a feature for programmers
We propose use of annotations to indicate to the runtime about the object's life-expectancy.
2 shows use of a custom annotation "ObjectAllocationPolicy".
3 shows the structure of the custom annotation.
When the above source code is compiled, the associated annotation will be included into the generated byte codes.
We propose to have an additional step during class loading during which the class loader will interpret the annotation and create internal data structures that wi...