Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1999-05-11
2004-03-02
Dam, Tuan (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C707S793000, C717S140000, C717S153000, C717S116000
Reexamination Certificate
active
06701520
ABSTRACT:
TECHNICAL FIELD
The present invention relates generally to the field of computer data processing, and more particularly to immunizing objects from garbage collection in object oriented programming, such as Java.
BACKGROUND OF THE INVENTION
Computer programming is the method by which humans tell computers how to perform a specific task; it typically comprises lists of instructions on how to retrieve, manipulate and store data. Previously, programming was procedural or step-by-step, that is, a programmer would tell the computer to fetch data A from space A and then fetch data B from space B and then add A+B and then store the answer in space C. For the most part, computers still require those instructions but the level of sophistication has increased. One type of programming, known as object-oriented programming (OOP), is becoming increasingly popular and may eventually supplant procedural programming. OOP languages, such as Smalltalk, C++, and Java, allow programmers to approach their programming tasks in a more natural and intuitive way than the rigidity of the procedural programming languages. The goal of OOP is to reduce the time and costs associated with developing complex software by creating small, reusable sections of program code that can be quickly and easily combined and reused to create new programs. The executable code sections and the data contained therein are known as objects. The software object may model the attributes or characteristics of the real-world object and, in many cases, may also model its behavior. For example, an OOP employee object may have certain attributes of a real employee, such as a name, an address, an employee number, and so forth. Exploiting the full capabilities of the OOP source code, the employee object could be used in a program corresponding to the way one would interact with a real employee. For instance, the employee object could provide the employee's address when asked for that information or provide the employee's status, e.g., “on vacation,” when asked for status information. Object-oriented databases (OODBs) that are specifically designed to facilitate storage and retrieval of objects have been developed. Objects that are stored in a data store are known as persistent objects because they “persist” after the program that created them ceases executing.
Java™ is a programming language that blossomed in the mid to late 1990s. The concept of Java was to remove software dependence on individual processors and into the realm of consumers, i.e., despite the fanaticism towards certain computer processors and operating systems exhibited by those knowledgeable in the computer industry, most consumers of electronic devices are irreverent when it comes to which particular processor or operating system is used to operate or function on their consumer electronic device so long as it works reliably and seamlessly. So, Java was initially developed for “smart” consumer electronic devices that could all be centrally controlled and programmed from a handheld remote control device, such as using the same software to operate a set-top box for video-on demand technology or a toaster. Java has flourished with burgeoning expansion of network computer technology and the rise of the world wide web browsing technology to facilitate access to the Internet. Java applications can then be written on one computer and transferred over a network, such as the world wide web, to any other consumer electronic device, such as another computer, that has a Java compiler or interpreter regardless of the operating system or the processor in that consumer electronic device.
One of the reasons Java is so productive and accepted is that Java doesn't require the programmer to manage memory deallocations, i.e., garbage collection is automatic and is done “under the covers.” In a pure Java program there's no such thing as a memory leak that exists in C/C++ and other languages. A memory leak occurs when memory is allocated but not deallocated after the memory is unreachable by the program. Memory is allocated at instantiation of an object. The purpose of garbage collection is to automatically reclaim memory from objects that are no longer referenced. While this is a nice scheme that makes programming easier and less prone to errors, the programmer has no absolute control over when the garbage collector runs other than to manipulate some parameters, e.g., the minimum and maximum garbage collection size and the frequency with which garbage collection is done. The garbage collector typically runs periodically at the discretion of the Java Virtual Machine (JVM). Different virtual machines support different strategies for garbage collection. The bottom line is that memory is reclaimed when there are no longer any references to an object.
Garbage collection works well in most programming situations. Lack of control over memory deallocations, however, sometimes presents problems. Two problems relating to garbage collection occur in memory-constrained and real-time applications. Because the programmer has no control over exactly when memory is released, applications that are severely memory-constrained will have to rely on the garbage collector to free up memory fast enough so that no significant performance penalties have to be paid. This is typically not a problem as garbage collection algorithms are well known in the art and are usually very efficient.
In real-time applications, however, garbage collection consumes substantial system resources when its runs. In these real-time applications timing is critical and the slowdown caused by garbage collection may not be acceptable. Because there is no way to predict precisely when the memory is going to be freed, i.e., when the garbage collector is going to be activated, finding a work around is a daunting task. The Java Runtime class provided a method gc( ) to facilitate garbage collection. A call to gc( ) may be made as follows:
// Tell the garbage collector to free up memory System.gc( );
Calling gc( ), however, doesn't deallocate memory; it is merely a suggestion to the virtual machine to run the garbage collector as soon as it can. When the garbage collector actually runs depends on the runtime environment and the implementation of the garbage collector.
Garbage collection is based on determining when an object in the runtime process is no longer in use. JVMs generate and maintain a list or table of objects contained within the JVM. As long as an active reference is in the object table, the object is reachable by the program. During the garbage collection process, the object table or list of objects is partitioned into two components: (1) active or live components; and (2) inactive objects that are no longer referenced or are dead. An object can be marked as inactive or dead so long as no other references still point to the object. Once marked as inactive, the memory can be reclaimed.
A technique for finer grain of control for Java program's interaction with the garbage collection is Reference Object Application Programming Interface (API). The reference object encapsulates a regular reference to a Java object. The API defines the following reference types: soft reference, weak reference, and phantom reference in order of reachability. The impact on garbage collection is that the weaker the reference the more the incentive for the garbage collector to free its memory. Creating appropriate references using the Reference Object API gives the programmer more control over what memory is freed by the garbage collector but there is still no disclosed way to prevent constant objects from being reclaimed.
There remains a need, however, to improve two critical aspects of the Java environment: object creation and garbage collection. It is thus an object of the invention to reduce the amount of object creation and garbage collection that occurs in JVMs running Java applications.
SUMMARY OF THE INVENTION
These and other objects of the invention are achieved by a method of object-oriented
Barsness Eric Lawrence
Santosuosso John Matthew
Dam Tuan
International Business Machines - Corporation
Kendall Chuck
Nock James R.
Ojanen Karuna
LandOfFree
Preventing garbage collection of objects in object oriented... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Preventing garbage collection of objects in object oriented..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Preventing garbage collection of objects in object oriented... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3271909