Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1999-09-16
2002-08-20
Shah, Sanjiv (Department: 2172)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000
Reexamination Certificate
active
06438560
ABSTRACT:
FIELD OF THE INVENTION
The invention is generally related to computers and computer software. More specifically, the invention is generally related to the creation of objects during execution of a computer program.
BACKGROUND OF THE INVENTION
Managing memory is critically important to the performance and reliability of a data processing system such as a computer. Specifically, data used by a computer program is typically stored in a computer within a memory that has a limited address space. In many computers, data is stored in the form of “objects” that are allocated space in a portion of the memory referred to as an “object heap”.
In many computer environments, objects are created, or “allocated”, dynamically (i.e., on an as-needed basis) during the execution of a computer program. In addition, given that the amount of memory available in a computer is limited, some mechanism for removing, or “deallocating”, unused objects is also provided, typically either through the use of specific program instructions or through an automated process known as garbage collection. One well known computer programming environment that utilizes dynamic memory allocation, for example, is the Java programming environment developed by Sun Microsystems.
One primary benefit of dynamic memory allocation is that the overall amount of memory required to run a computer program is typically reduced, often reducing the memory requirements of a computer upon which the program is executed, or permitting more computer programs to share a given memory space in the computer. Computer performance may also benefit due to the reduced memory requirements, since less swapping of data into and out of memory may be required. Another benefit is that overall reliability of the computer is often improved since memory usage is typically better managed.
The primary drawback to dynamic memory management, however, is the additional “overhead” that is associated with both allocating and deallocating objects. Allocating and deallocating an object each require the computer to perform certain operations that are outside of the actual productive operations that are being performed during execution of a computer program. These additional operations delay the performance of the productive operations, which typically slows the overall operation of the computer. Therefore, for performance concerns, it is highly desirable to minimize whenever possible the number of object allocation and deallocation operations performed by a computer program.
One particular area of concern for dynamically-managed memory systems is the concept of “immutable” objects, which are objects that cannot be modified after they are created. Some immutable objects are “short lived”, as they may only be used briefly, and may quickly become candidates for deallocation. Also, in systems in which deallocation is done automatically, such objects tend to linger and take up space in the object heap between garbage collection cycles. In such instances, the overhead associated with allocating and deallocating these objects is disproportionally high relative to “longer lived” objects.
Other immutable objects may be long lived, particularly in instances where the objects are created as part of an interrelated network of objects. Typically, the entire network of objects is maintained in the object heap until processing of the entire network is completed. As such, while an immutable object in such a network may not be routinely used, the interrelationships between the immutable object and other objects in the network may prevent the immutable object from being deallocated for some period of time.
As one example, accessing records in a database often results in the creation of a relatively large number of immutable objects. In the Java programming environment, for example, the results of a search request are typically stored in a “ResultSet” object, which can include multiple records, with each record having multiple fields. The ResultSet class supports a function known as “getstring( )” to retrieve the contents of a particular field in a current record in a ResultSet object. The getString( ) function generally operates by accessing the requested contents, creating a new String object containing the requested contents and returning a reference for the new object to the calling routine. In Java, String objects are typically implemented as immutable objects, so the typical result of each getString( ) operation is the creation of an immutable object.
In many situations, a ResultSet object can include a large number of records (each with multiple fields) that are processed iteratively, necessitating repeated getString( ) operations, and hence, the creation of a large number of immutable objects. Moreover, data stored in a database is often hierarchical in nature, and that hierarchy is often reflected in the access pattern. Due to this common characteristic of databases, a large number of immutable objects created during an access to a ResultSet object can contain identical contents, resulting a significant portion of an object heap being filled with essentially redundant data.
For example, consider a database of customers that includes records containing the name and address of each customer, with the records primarily sorted by state, then city, then street, etc. Particularly if the owner of the database is large or is predominantly local, it is possible for large numbers of records to have identical data stored in the state fields thereof. However, should a significant portion of those records be accessed in response to the same query, a different immutable object would still be created for the state information in each record, despite the fact that each such object would contain the same information.
The creation, and later deallocation, of large numbers of redundant immutable objects decreases available storage and introduces processing overhead, both of which decrease performance. As a result, a substantial need exists for a manner of minimizing the overhead associated with redundant immutable objects.
SUMMARY OF THE INVENTION
The invention addresses these and other problems associated with the prior art by providing an apparatus, program product, and method of processing a request to create an immutable object in which an existing immutable object is reused in appropriate circumstances to represent redundant data without the necessity for creating an additional immutable object. Specifically, prior to creating a new object in response to a request to create an immutable object, a determination is made as to whether a matching immutable object already exists that has redundant content with respect to the requested immutable object. If so, creation of a new object is inhibited, and a reference to the matching immutable object is returned in response to the request.
Given that immutable objects, by definition, cannot change over time, reuse of such objects for multiple purposes, even at the same time, does not raise any reliability concerns. Moreover, the potential savings in storage and processing overhead (due to reduced allocation and deallocation operations) can be significant in many instances, resulting in improved overall performance.
While the hereinafter described embodiments of the invention may be utilized in other applications, one particular application for which a significant benefit may be derived is in accessing data from a database. In particular, it may be desirable to implement immutable object reuse to reduce the number of immutable objects created when accessing data from a result set that has been generated in response to a database query. Retrieval of data from the result set may include generating a request for an immutable object in the result set, which is processed by first determining whether a matching immutable object exists having redundant content with respect to the requested immutable object, and then, based on the result, either returning a reference to the matching immutable object as a response to the request, or if none exists, creating
Shah Sanjiv
Wood Herron & Evans LLP
LandOfFree
Reuse of immutable objects during object creation does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Reuse of immutable objects during object creation, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Reuse of immutable objects during object creation will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2944526