Electrical computers and digital processing systems: memory – Storage accessing and control – Hierarchical memories
Reexamination Certificate
2000-12-13
2004-04-06
Bragdon, Reginald G. (Department: 2188)
Electrical computers and digital processing systems: memory
Storage accessing and control
Hierarchical memories
C711S133000, C711S173000
Reexamination Certificate
active
06718438
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to persistent object systems, and in particular to sizing an object cache using feedback from the execution of a persistent object system.
Sun, Sun Microsystems, the Sun logo, Solaris, Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. All SPARC trademarks are used under license and are trademarks of SPARC International, Inc. in the United States and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. Gemstone/J is a trademark or registered trademark of GemStone Systems Inc. in the United States and other countries. Motorola and 680X0 are trademarks or registered trademarks of Motorola Inc in the United States and other countries. Intel, 80X86, and Pentium are trademarks or registered trademarks of Intel Corporation in the United States and other countries.
2. Background Art
Persistent object systems are designed to handle data that continues to exist, even after the process that created it has stopped executing. In contrast, transient object systems are designed to handle data only during the execution of the process that created the object. A heap is an area of memory reserved for objects that are created at runtime—that is, when the program actually executes. The persistent object system provides the illusion of a very large object heap because it is not limited only to objects that are created at runtime. Instead, a persistent object system may operate on both transient objects and persistent objects which are automatically backed up by secondary storage. The persistent objects may be stored in memory separately from transient objects or may be stored together in the heap.
Persistent objects are automatically saved to secondary storage, typically a stable storage medium such as a disk drive, and fetched from secondary storage into virtual memory on demand. The persistent object system implements automatic secondary storage management. Objects are accessed uniformly in virtual memory, regardless of whether they are transient or persistent. Persistent objects are written to storage when the program performs a “checkpoint. ” A checkpoint is a snapshot of the state of the object at that moment in time. A complete description of one embodiment of a checkpointing scheme is described in co-pending U.S. patent application entitled “Method and Apparatus for Hybrid Checkpointing” Ser. No. 09/652,217 filed on Aug. 31, 2000, now U.S. Pat. No. 6,275,443, issued Aug. 14, 2001, assigned to the assignee of the present application, and hereby fully incorporated into the present application by reference. Objects are automatically read (faulted in) from the store when the program refers to them. This allows a long lived program's computation to survive in stable storage, across multiple executions, and despite system failures. An example of a persistent object platform is described below.
Persistent Object Platform
An example of a persistent object platform is one that implements the Java platform. A program which utilizes Java technology is composed of a number of classes and interfaces. Unlike many programming languages, in which a program is compiled into machine-dependent, executable program code, programs which utilize Java technology are compiled into machine independent bytecode class files. Each class contains code and data in a platform-independent format called the class file format. The computer system acting as the execution vehicle contains a program called a virtual machine, which is responsible for executing the code in classes. The virtual machine provides a level of abstraction between the machine independence of the bytecode classes and the machine-dependent instruction set of the underlying computer hardware.
FIG. 1
is a block diagram illustrating a sample network application environment, for instance a Java network application environment, comprising a client platform
102
coupled over a network
101
to a server
100
for the purpose of accessing class files for execution of an application or applet.
Sample Network Application Environment
In
FIG. 1
, server
100
comprises development environment
104
for use in creating the class files for a given application. The development environment
104
provides a mechanism, such as an editor and an applet viewer, for generating class files and previewing applets. A set of core classes
103
comprise a library of classes that can be referenced by source files containing other classes. From development environment
104
, one or more source files
105
are generated. Source files
105
contain the programmer readable class definitions, including data structures, method implementations and references to other classes. Source files
105
are provided to compiler
106
, which compiles source files
105
into compiled “.class” files
107
that contain bytecodes executable by a virtual machine. Bytecode class files
107
are stored (e.g., in temporary or permanent storage) on server
100
, and are available for download over network
101
.
Client platform
102
contains a virtual machine (VM)
111
which, through the use of available native operating system (O/S) calls
112
, is able to execute bytecode class files and execute native O/S calls when necessary during execution. Class files are often identified in applet tags within an HTML (hypertext markup language) document. A web server application
108
is executed on server
100
to respond to HTTP (hypertext transport protocol) requests containing URLs (universal resource locators) to HTML documents, also referred to as “web pages.” When a browser application executing on client platform
102
requests an HTML document, such as by forwarding URL
109
to web server
108
, the browser automatically initiates the download of the class files
107
identified in the applet tag of the HTML document. Class files
107
are typically downloaded from the server and loaded into virtual machine
111
individually as needed.
It is typical for the classes of a program to be loaded as late during the program's execution as possible; they are loaded on demand from the network (stored on a server), or from a local file system, when first referenced during the program's execution. The virtual machine locates and loads each class file, parses the class file format, allocates memory for the class's various components, and links the class with other already loaded classes. This process makes the code in the class readily executable by the virtual machine.
Object Cache Management
Objects read from stable storage into virtual memory (“persistent objects”) are stored in an “object cache”. In general, caches are implemented under the assumption that it is very likely that some object or piece of data will be repeatedly accessed. Access delays are minimized by keeping popular data close to the entity which needs it. A cache comprises a finite area of a computer's memory and, as stated above, can be combined to contain both transient and persistent objects. Thus, the total space for all memory-resident persistent objects may exceed some proportion of the total cache size, called a “budget”. When the persistent objects in the cache exceed the size of the budget they must be removed from the cache. Removing such objects from the cache is termed “eviction”. Once an object is evicted, it must be read from the store the next time it is needed. Thus, it is important to try to not evict objects that are likely to be used again in the near future. Current eviction schemes are inadequate at determining whether an object marked for eviction is likely to be used in the near future.
Current Schemes for Managing the Object Cache
Using current schemes, a persistent object system's object cache is implemented either by using a combined heap (i.e., combining the heap with the object cache) or by using a separate storage area. Using a combine
Gafter Neal M.
Jordan Michael J.
Lewis Brian T.
Mathiske Bernd J. W.
Bragdon Reginald G.
Park Vaughan & Fleming LLP
Sun Microsystems Inc.
LandOfFree
Using feedback to determine the size of an object cache does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Using feedback to determine the size of an object cache, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Using feedback to determine the size of an object cache will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3275102