Patent Application
20060167961
1. Technical Field
The present invention is generally directed to an improved data processing system. More specifically, the present invention is directed to automatically regulating a cache object array based on the amount of available heap.
2. Description of Related Art
The memory utilization of a Java™ heap is an important characteristic of program performance. Whenever a class instance or array is created in a running Java™ application, the memory of the new cache object is allocated from a single heap. Because a Java™ application runs inside its “own” exclusive Java Virtual Machine (JVM™) instance, a separate heap exists for every individual running application. As only one heap exists inside a JVM™ instance, all threads share it.
A “new” construct in Java™ is supported in the JVM™ by allocating memory on the heap for a new cache object. The allocation of memory dedicated to object caching is performed by a user and requires the user to have some basic knowledge of cache tuning. Also, the allocation of the memory dedicated to object caching is static until the user decides to change the size of the allocation. Thus, the virtual machine itself is responsible for deciding whether and when to free memory occupied by cache objects that are no longer referenced by the running application due to the defined cache object space. Usually, a JVM™ implementation uses a garbage collector to manage the heap and clean up the heap, i.e. identify cache objects that no longer have active references in the running application to them and free the memory associated with these “dead” cache objects.
The garbage collector's primary function is to automatically reclaim the memory used by objects that are no longer reference by the running application. It also can move objects as the application runs to reduce heap fragmentation. The memory that makes up the heap need not be contiguous and can be expanded and contracted as the running program progresses and the space allocated for cached object does not change as the allocation is set by the user.
Even though the heap is a limited resource, the amount of space allocated to object caching may be manually changed based upon heap usage. Actual changing of the space allocated to object caching requires a user to know the requirements of heap sizing, garbage collecting and cache tuning. Thus, it would be advantageous to have a method and system for automatically regulating a cache object array based on the amount of available heap.
The present invention provides a method, system and computer instructions for automatically regulating a cache object array based on the amount of free continuous space within the heap. Within the present invention, the free space of the heap is determined after each garbage collection cycle and the amount of space allocated for cache object growth is regulated accordingly.
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
The present invention is directed to automatically regulating a cache object array based on the amount of available heap. The present invention is preferably used with computing devices that are part of a distributed data processing environment, such as the Internet, a wide area network (WAN), local area network (LAN), or the like, but is not limited to such and may be used in a stand-alone computing system or completely within a single computing device. The following
With reference now to the figures,
In the depicted example, server 104 is connected to network 102 along with storage unit 106. In addition, clients 108, 110, and 112 are connected to network 102. These clients 108, 110, and 112 may be, for example, personal computers or network computers. In the depicted example, server 104 provides data, such as boot files, operating system images, and applications to clients 108-112. Clients 108, 110, and 112 are clients to server 104. Network data processing system 100 may include additional servers, clients, and other devices not shown. In the depicted example, network data processing system 100 is the Internet with network 102 representing a worldwide collection of networks and gateways that use the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, government, educational and other computer systems that route data and messages. Of course, network data processing system 100 also may be implemented as a number of different types of networks, such as for example, an intranet, a local area network (LAN), or a wide area network (WAN).
Referring to
Peripheral component interconnect (PCI) bus bridge 214 connected to I/O bus 212 provides an interface to PCI local bus 216. A number of modems may be connected to PCI local bus 216. Typical PCI bus implementations will support four PCI expansion slots or add-in connectors. Communications links to clients 108-112 in
Additional PCI bus bridges 222 and 224 provide interfaces for additional PCI local buses 226 and 228, from which additional modems or network adapters may be supported. In this manner, data processing system 200 allows connections to multiple network computers. A memory-mapped graphics adapter 230 and hard disk 232 may also be connected to I/O bus 212 as depicted, either directly or indirectly.
Those of ordinary skill in the art will appreciate that the hardware depicted in
The data processing system depicted in
With reference now to
In the depicted example, local area network (LAN) adapter 312, audio adapter 316, keyboard and mouse adapter 320, modem 322, read only memory (ROM) 324, hard disk drive (HDD) 326, CD-ROM driver 330, universal serial bus (USB) ports and other communications ports 332, and PCI/PCIe devices 334 may be connected to ICH 310. PCI/PCIe devices may include, for example, Ethernet adapters, add-in cards, PC cards for notebook computers, etc. PCI uses a cardbus controller, while PCIe does not. ROM 324 may be, for example, a flash binary input/output system (BIOS). Hard disk drive 326 and CD-ROM drive 330 may use, for example, an integrated drive electronics (IDE) or serial advanced technology attachment (SATA) interface. A super I/O (SIO) device 336 may be connected to ICH 310.
An operating system runs on processor 302 and is used to coordinate and provide control of various components within data processing system 300 in
Instructions for the operating system, the object-oriented programming system, and applications or programs are located on storage devices, such as hard disk drive 326, and may be loaded into main memory 304 for execution by processor 302. The processes of the present invention are performed by processor 302 using computer implemented instructions, which may be located in a memory such as, for example, main memory 304, memory 324, or in one or more peripheral devices 326 and 330.
Those of ordinary skill in the art will appreciate that the hardware in
For example, data processing system 300 may be a personal digital assistant (PDA), which is configured with flash memory to provide non-volatile memory for storing operating system files and/or user-generated data. The depicted example in
Although the present invention may operate on a variety of computer platforms and operating systems, it may also operate within an interpretive environment, such as a REXX™, Smalltalk™, or Java™ runtime environment, and the like. For example, the present invention may operate in conjunction with a Java Virtual Machine (JVM™) yet within the boundaries of a JVM™ as defined by Java™ standard specifications. In order to provide a context for the present invention with regard to an exemplary interpretive environment, portions of the operation of a JVM™ according to Java™ specifications are herein described.
With reference now to
The JVM™ is a virtual computer, i.e. a computer that is specified abstractly. The specification defines certain features that every JVM™ must implement, with some range of design choices that may depend upon the platform on which the JVM™ is designed to execute. For example, all JVM™s must execute Java™ bytecodes and may use a range of techniques to execute the instructions represented by the bytecodes. A JVM™ may be implemented completely in software or somewhat in hardware. This flexibility allows different JVM™S to be designed for mainframe computers and PDAs.
The JVM™ is the name of a virtual computer component that actually executes Java™ programs. Java™ programs are not run directly by the central processor but instead by the JVM™, which is itself a piece of software running on the processor. The JVM™ allows Java™ programs to be executed on a different platform as opposed to only the one platform for which the code was compiled. Java™ programs are compiled for the JVM™. In this manner, Java™ is able to support applications for many types of data processing systems, which may contain a variety of central processing units and operating systems architectures. To enable a Java™ application to execute on different types of data processing systems, a compiler typically generates an architecture-neutral file format—the compiled code is executable on many processors, given the presence of the Java™ run-time system.
The Java™ compiler generates bytecode instructions that are nonspecific to a particular computer architecture. A bytecode is a machine independent code generated by the Java™ compiler and executed by a Java™ interpreter. A Java™ interpreter is part of the JVM™ that alternately decodes and interprets a bytecode or bytecodes. These bytecode instructions are designed to be easy to interpret on any computer and easily translated on the fly into native machine code.
A JVM™ must load class files and execute the bytecodes within them. The JVM™ contains a class loader, which loads class files from an application and the class files from the Java™ application programming interfaces (APIs) which are needed by the application. The execution engine that executes the bytecodes may vary across platforms and implementations.
One type of software-based execution engine is a just-in-time (JIT) compiler. With this type of execution, the bytecodes of a method are compiled to native machine code upon successful fulfillment of some type of criteria for “jitting” a method. The native machine code for the method is then cached and reused upon the next invocation of the method. The execution engine may also be implemented in hardware and embedded on a chip so that the Java™ bytecodes are executed natively. JVM™s usually interpret bytecodes, but JVM™s may also use other techniques, such as just-in-time compiling, to execute bytecodes.
When an application is executed on a JVM™ that is implemented in software on a platform-specific operating system, a Java™ application may interact with the host operating system by invoking native methods. A Java™ method is written in the Java™ language, compiled to bytecodes, and stored in class files. A native method is written in some other language and compiled to the native machine code of a particular processor. Native methods are stored in a dynamically linked library whose exact form is platform specific.
With reference now to
Runtime data areas 454 contain native method stacks 464, Java™ stacks 466, PC registers 468, method area 470, and heap 472. These different data areas represent the organization of memory needed by JVM™ 450 to execute a program.
Java™ stacks 466 are used to store the state of Java™ method invocations. When a new thread is launched, the JVM™ creates a new Java™ stack for the thread. The JVM™ performs only two operations directly on Java™ stacks: it pushes and pops frames. A thread's Java™ stack stores the state of Java™ method invocations for the thread. The state of a Java™ method invocation includes its local variables, the parameters with which it was invoked, its return value, if any, and intermediate calculations. Java™ stacks are composed of stack frames. A stack frame contains the state of a single Java™ method invocation. When a thread invokes a method, the JVM™ pushes a new frame onto the Java™ stack of the thread. When the method completes, the JVM™ POPS the frame for that method and discards it.
The JVM™ does not have any registers for holding intermediate values; any Java™ instruction that requires or produces an intermediate value uses the stack for holding the intermediate values. In this manner, the Java™ instruction set is well-defined for a variety of platform architectures.
PC registers 468 are used to indicate the next instruction to be executed. Each instantiated thread gets its own pc register (program counter) and Java™ stack. If the thread is executing a JVM™ method, the value of the pc register indicates the next instruction to execute. If the thread is executing a native method, then the contents of the pc register are undefined.
Native method stacks 464 store the state of invocations of native methods. The state of native method invocations is stored in an implementation-dependent way in native method stacks, registers, or other implementation-dependent memory areas. In some JVM™ implementations, native method stacks 464 and Java™ stacks 466 are combined.
Method area 470 contains class data while heap 472 contains all instantiated objects. The JVM™ specification strictly defines data types and operations. Most JVM™s choose to have one method area and one heap, each of which are shared by all threads running inside the JVM™. When the JVM™ loads a class file, it parses information about a type from the binary data contained in the class file. It places this type information into the method area. Each time a class instance or array is created, the memory for the new object is allocated from heap 472. JVM™ 450 includes an instruction that allocates memory space within the memory for heap 472 but includes no instruction for freeing that space within the memory. Memory management 474 in the depicted example manages memory space within the memory allocated to heap 470. Memory management 474 may include a garbage collector which automatically reclaims memory used by objects that are no longer referenced. Additionally, a garbage collector also may move objects to reduce heap fragmentation.
The garbage collector performs operations generally referred to as mark/sweep/compact. These operations are the marking of live objects and coalescing sequences of dead objects and spaces that are not marked as live to thereby free or reclaim memory space. Any fragmentation caused by the live objects within the heap is compacted during the compact operation. Compaction moves objects toward one end of the heap with the goal of creating the largest possible contiguous free area or areas. Compaction helps to avoid allocating new memory to expand the heap size. More information about garbage collection may be found in Dimpsey et al., “Java™ Server Performance: A Case Study of Building Efficient, Scalable JVM™s,” IBM System's Journal, January 2000, which is hereby incorporated by reference.
Thus, the present invention provides for automatically regulating a cache object array based on the amount of free continuous space within the heap. Within the present invention, the free space of the heap is determined after each garbage collection cycle and the amount of space allocated for cache object growth is regulated accordingly.
With reference now to
The illustrative examples of the present invention make use of the mark and sweep operations of garbage collection to identify the free space within the heap allocation.
For example, if the average occupied heap size 604 is shown after garbage collection has run and is shown as 66 percent of maximum heap size 602 and, thus, the average free space 606 is the other 34 percent. The present invention then allows the allocation of the allowable cache object array 610 to be 50 percent of the average free space 606 which makes the allowable cache object array 610 to be 17 percent of the maximum heap size 602. Thus the present invention allows for regulation of cache object array 610 depending on heap size 602.
In
The preferred operation of the present invention begins by allocating a default cache object array (block 702). The cache object array represents a typical FIFO type array, such as session data. The default allocation of the cache object array may be, for example, a minimum size of 10 megabytes and a maximum size of 25 percent of maximum heap size or 50 percent of average free space. A decision is then made as to whether the system has run for a predefined amount of time (block 704). The predefined amount of time is for the computer to warm-up and the processes running on the computer to stabilize. This time may be, for example, one hour or another time that is known by the user as an average of time it takes the system to warm-up. If the system has not run for the predetermined time, the allocation for the cache object array is maintained at the default settings. If the system has run for the predetermined amount of time and the heap has started to stabilize, the average free space of the heap is determined (block 706). The average free space is determined by the subtracting the average occupied heap size after garbage collection from the maximum heap size specified by the user. Based on the average free space, the cache object array is allowed add more objects into the array and grow to 50 percent of the average free space (block 708). At block 710, a determination of whether garbage collection has run. If so, the operation returns to block 706 and the average free space is again determined and based on the average free space, the cache object array is allowed add more objects into the array and grow to 50 percent of the average free space (block 708). If at block 710, garbage collection has not run then a determination of the size of the cache object array is made (block 712). If the cache object array is not larger than 50 percent of the average free space, the operation returns to block 708 and the cache object array is allowed to grow up to 50 percent of the average free space. If at block 712 the cache object array is larger than 50 percent of the average free space, entries are removed from the cache object array until the size is below 50 percent of the average free space and the process returns to block 710. One method to remove cached objects from the array would be to perform a standard FIFO cleanup.
Thus, the present invention provides mechanisms for automatically regulating a cache object array based on the amount of available heap. As a result, the cache object array size changes automatically with changes in the heap size and free space. The present invention avoids a user having to understand cache tuning and manually change cache object array size when needed.
It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media, such as a floppy disk, a hard disk drive, a RAM, CD-ROMs, DVD-ROMs, and transmission-type media, such as digital and analog communications links, wired or wireless communications links using transmission forms, such as, for example, radio frequency and light wave transmissions. The computer readable media may take the form of coded formats that are decoded for actual use in a particular data processing system.
The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. Though the examples presented are directed toward Java applications, the present invention may be applied to other programming environments that use heaps. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
