Centralized cache storage for runtime systems

Abstract

Described herein are methods and apparatus, including computer program products, that implement a centralized cache storage for runtime systems. A computer program product can include instructions operable to receive a request at a centralized shared cache framework to store an entity; cache the entity in a shared memory in response to the request, where the shared memory is operable to store the entity such that the entity is accessible to runtime systems, and caching the entity in the shared memory comprises storing the entity for one of the runtime systems; receive a request at the centralized shared cache framework to retrieve the entity from the shared memory; and if the entity is stored in the shared memory, retrieve the stored entity from the shared memory, where the centralized shared cache framework is operable to retrieve the entity for any of the runtime systems.

Description

BACKGROUND

The present application relates to digital data processing, and more particularly to centralized cache storage for runtime systems.

A runtime system is a code execution environment that executes instructions or code in user requests and that provides runtime services for that code. Core runtime services can include functionality such as process, thread, and memory management (e.g., laying out entities in a server memory, managing references to entities, and garbage collecting entities). Enhanced runtime services can include functionality such as error handling and establishing security and connectivity.

One example of a runtime system is a virtual machine (VM). A VM is an abstract machine that can include an instruction set, a set of registers, a stack, a heap, and a method area, like a real machine or processor. A VM essentially acts as an interface between program code and the actual processor or hardware platform on which the program code is to be executed. The program code includes instructions from the VM instruction set that manipulate the resources of the VM. The VM executes instructions on the processor or hardware platform on which the VM is running, and manipulates the resources of that processor or hardware platform, so as to effect the instructions of the program code. In this way, the same program code can be executed on multiple processors or hardware platforms without having to be rewritten or re-compiled for each processor or hardware platform. Instead, a VM is implemented for each processor or hardware platform, and the same program code can be executed in each VM. The implementation of a VM can be in code that is recognized by the processor or hardware platform. Alternatively, the implementation of a VM can be in code that is built directly into a processor.

As an example, a Java source program can be compiled into program code known as bytecode. Bytecode can be executed on a Java VM running on any processor or platform. The Java VM can either interpret the bytecode one instruction at a time, or the bytecode can be further compiled for the real processor or platform using a just-in-time (JIT) compiler.

In addition to Java VMs, other examples of VMs include Advanced Business Application Programming language (ABAP) VMs and Common Language Runtime (CLR) VMs. ABAP is a programming language for developing applications for the SAP R/3 system, a widely installed business application system developed by SAP. The CLR is a managed code execution environment developed by Microsoft Corp. of Redmond, Wash.

When executing, runtime systems create and reference local data entities. Many different types of local entities can be created, including, for example, strings, constants, and variables, objects that are instances of a class, runtime representations of a class, and class loaders that are used to load class runtime representations.

When a local entity is no longer being used by a runtime system, the memory being used to store the local entity needs to be reclaimed—i.e., freed or otherwise released and returned to the pool of available memory—so that it can be used to store new data entities. In some environments, programmers must explicitly reclaim the memory they have allocated for local entities (e.g., by explicitly calling functions to free specified sections of memory). In other environments, the reclamation of memory is handled through a technique known as garbage collection.

Garbage collection is a process designed to identify and reclaim blocks of memory that have been dispensed by a memory allocator but that are no longer “live” (i.e., no longer being used, as determined, for example, by not being reachable from any currently referenced objects or entities). Entities that are garbage collected are typically referred to as being “dead” as opposed to being live. Garbage collection is usually handled as a background task by runtime systems rather than as an explicit task by user programs. There are some costs associated with garbage collection, as access to memory must typically be restricted and runtime systems must sometimes be halted during some portions of the garbage collection process.

Multiple runtime systems can be executed in parallel in order to increase the performance and scalability of server environments. When multiple runtime systems are executed in parallel, resource (e.g., memory) and time consumption can be reduced by sharing entities between the runtime systems. There are multiple techniques that can be used to share entities, and many different types of entities can be shared (including for example strings, constants, variables, object instances, class runtime representations, and class loaders).

A runtime system can include a cache, which is a temporary storage, in a memory, for entities. In some implementations, entities in a cache can be directly accessed by programs running in the runtime system. For example, a program can store and retrieve entities in the cache. In a cache for a Java VM, objects can be cached in a local heap.

SUMMARY

Described herein are methods and apparatus, including computer program products, that implement a centralized cache storage for runtime systems.

In one general aspect, a computer program product, tangibly embodied in an information carrier, includes instructions operable to cause data processing apparatus to receive a request at a centralized shared cache framework to store an entity; cache the entity in a shared memory in response to the request, where the shared memory is operable to store the entity such that the entity is accessible to runtime systems, and caching the entity in the shared memory comprises storing the entity for one of the runtime systems; receive a request at the centralized shared cache framework to retrieve the entity from the shared memory; and if the entity is stored in the shared memory, retrieve the stored entity from the shared memory, where the centralized shared cache framework is operable to retrieve the entity for any of the runtime systems.

Implementations can include one or more of the following features. The instructions to cache the entity in shared memory can include instructions to interface the centralized shared cache framework with a storage plug-in to store the entity in a type of memory that is associated with the storage plug-in. The instructions to cache the entity in shared memory can include instructions to cache a shared closure of entities. The instructions to cache a shared closure of entities can include instructions to cache versions of shared closures of entities. The instructions to cache a shared closure of entities can include instructions to cache at least two types of shared closures, the types of shared closures including a first type corresponding to shared closures being mappable; and a second type corresponding to shared closures being copy-only.

The computer program product can further include instructions to lock the second type of shared closures to prevent multiple accesses to a copy-only shared closure. The instructions to retrieve the stored entity from the shared memory can include instructions to retrieve a cached entity that is of the first type of shared closure by mapping the cached entity to a runtime system. The instructions to retrieve the stored entity from the shared memory can include instructions to retrieve a cached entity that is of the second type of shared closure by copying the cached entity to a local memory of a runtime system. The computer program product can further include instructions to determine the memory used by cached entities. The runtime systems can be virtual machines, including Java virtual machines.

In another aspect, a computer program product, tangibly embodied in an information carrier, includes instructions operable to cause data processing apparatus to receive a request at a cache framework from Java virtual machines to determine an amount of memory used by the cache framework; determine a first amount of memory used by the cache framework; and send the first amount in response to the request.

In another aspect, a server computer system includes a shared memory operable to store entities accessible to runtime systems; and a centralized shared cache framework operable to perform operations including caching entities for one of the runtime systems in the shared memory, where the shared cache framework stores the cached entities in the shared memory and the centralized shared cache framework enables access to the cached entities to runtime systems such that any of the runtime systems can access a same entity.

Implementations can include one or more of the following features. The server computer system can further include an interface for different cache storage plug-ins, each storage plug-in associated with a type of memory and operable to interface the type of memory with the centralized shared cache framework. The server computer system can further include a cache storage plug-in operable to interface a database with the shared cache framework. Caching entities can include caching shared closures of entities. The centralized shared cache framework can be further operable to determine an amount of memory consumed by cached entities. The cache framework can be further operable to determine the memory consumed by the cached entities based on a function operable to determine an amount of memory used by a shared closure of entities. The runtime systems can be Java virtual machines.

In another aspect, a server computer system includes at least one memory; at least one Java virtual machine; and a cache framework operable to perform operations including caching entities for the at least one Java virtual machine in the at least one memory; and determining an amount of memory used by the cache framework in the at least one memory.

The centralized cache storage for runtime systems described here can be implemented to realize one or more of the following advantages.

A centralized cache in shared memory is provided. Because the cache is shared, multiple runtime systems can access the same cache entries. Also, because the cache is centralized (e.g., rather than distributed), multiple copies of an entity in the cache need not be made. In addition, administration costs for a cache framework can be reduced, as there may be less administration required for a centralized cache framework than other types of caches. For example, process communication required between runtime systems to ensure consistency in a distributed shared cache need not be implemented in a centralized cache, as there need not be multiple copies of an entity. Because the cache is centralized, locks can be used and access to entities in the cache can be prevented such that an access to an entity in the cache does not risk being updated by multiple runtime systems at the same time. For example, without locks, a first and second runtime system may concurrently access the same-cached entity in a centralized cache. In that example, if the first runtime system updates the object, undesirable and/or unexpected behavior can occur (e.g., because the second runtime system did not foresee changes to the entity while the second runtime system is accessing the entity).

A centralized shared cache can support versioning of cached entities. By supporting versioning, cached entities can be accessed and modified by multiple runtime systems. The cache framework can support caching of shared closures of entities such that entities that would otherwise not be shareable across runtime systems, because of an affinity between the runtime system and the entities (e.g., by having pointers or references into any private heap), can be stored in a shared memory and cached across runtime systems. The cache framework can use a function to determine the memory usage of the cache and, thus, can limit the overall cache size (i.e., amount of memory consumed by a shared cache memory).

Details of one or more implementations are set forth in the accompanying drawings and the description below. Other features and advantages may be apparent from the description and drawings, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other aspects will now be described in detail with reference to the following drawings.

FIG. 1 is a block diagram of an exemplary client/server system.

FIGS. 2A and 2B illustrate the sharing of entities between VMs in a client/server system.

FIGS. 3 and 4 are flowcharts illustrating processes for creating and using shared objects.

FIG. 5 is an illustration of a system landscape including multiple VMs, a centralized shared memory, and a shared cache framework manager.

FIG. 6 is a flowchart of a process of responding to a user request to store an entity in a cache.

FIG. 7 is a flowchart of a process of responding to a user request to retrieve an entity from a cache.

FIG. 8 is an illustration corresponding to a cache system in which multiple thresholds are associated with multiple fill metrics.

FIG. 9 is a flowchart of a process of evicting cached entries.

Like reference numbers and designations in the various drawings indicate like elements.

DETAILED DESCRIPTION

A Client/Server System

FIG. 1 illustrates a client/server system 50 in which a network 75 links a server 80 to client systems 62, 64, and 66. The server 80 is a programmable data processing system suitable for implementing apparatus, programs, or methods in accordance with the description. The server 80 provides a core operating environment for one or more runtime systems that process user requests. The server 80 includes a processor 85 and a memory 90. The memory 90 can be used to store an operating system, a Transmission Control Protocol/Internet Protocol (TCP/IP) stack for communicating over the network 75, and machine-executable instructions executed by the processor 85. In some implementations, the server 80 can include multiple processors, each of which can be used to execute machine-executable instructions. The memory 90 can include a shared memory area 92 that is accessible by multiple operating system processes executing in the server 90. An example of a suitable server that can be used in the client/server system 50 is a Java 2 Platform, Enterprise Edition (J2EE) compatible server (Java virtual machine specification available from Sun Microsystems, Santa Clara, Calif.), such as the Web Application Server developed by SAP AG of Walldorf (Baden), Germany (SAP), or the WebSphere Application Server developed by IBM Corp. of Armonk, N.Y.

Client systems 62, 64, and 66 can execute multiple applications or application interfaces. Each instance of an application or an application interface can constitute a user session. Each user session can generate one or more requests to be processed by the server 80. The requests can include instructions or code to be executed on a runtime system (e.g., the virtual machine 100) on the server 80.

Shared Closures

Runtime systems can share data entities in order to reduce resource and time consumption (e.g., the time required to build and initialize multiple copies of an object, and the memory required to store those copies). Entities can be shared through various techniques. For example, entities can be shared by storing them in a shared memory area or heap that is accessible by multiple runtime systems.

In general, entities that are shared through a shared memory heap should not have any pointers or references into any private heap (e.g., the local memories of individual VMs). If an entity in the shared memory heap has a member variable with a reference to a private entity in one particular VM, that reference would be invalid for other VMs that use that shared entity. More formally, this restriction can be thought of as follows: for every shared entity, the transitive closure of the entities referenced by the initial entity should only contain shared entities at all times.

Accordingly, in one implementation, entities are not put into the shared memory heap by themselves—rather, entities are put into the shared memory heap in groups known as “shared closures.” A shared closure is an initial entity plus the transitive closure of all the entities referenced by the initial entity.

The sharing of entities through shared closures is shown conceptually in FIG. 2A, where a shared closure 450 has been identified in the local memory of a first VM 400 by grouping a first data entity 410 with the transitive closure of all the entities referenced by the first entity 410. After the shared closure 450 has been identified, the VM 400 can create the shared closure in a shared memory area 92, for example, by copying the shared closure 450 into the shared memory area 92. After the shared closure 450 has been created in the shared memory area 92, it can be accessed by the VMs in the server (e.g., VMs 200 and 400). A VM can access the shared closure 450 from the shared memory area 92 by, for example, mapping or copying the shared closure 450 from the shared memory area 92 into the address space of a process in which the VM is executing.

In order to qualify for use within a shared closure, an entity must be “shareable.” In general, a complex data structure (e.g., a heap or a portion thereof) in one runtime system (e.g., a Java VM) can be shared with a second runtime system if the data structure can be disassembled and then reassembled in the native format of the second runtime system without breaking the internal consistency or functionality of the data structure.

In one implementation, entities are shared through the copying of shared closures to and from shared memory. For an entity to be shareable in such an implementation, the entity has to withstand a transparent deep-copy into the address space of another VM without breaking the internal consistency or functionality of the entity. The shareability conditions for such an implementation generally require the class of which the entity is an instance not to execute any custom code in serializing or deserializing an instance of the class. Additional details about techniques for sharing entities (including shareability requirements and the creation and use of shared closures) can be found in, for example, U.S. patent application Ser. No. 10/851,795, entitled “Sharing Objects in Runtime Systems,” filed on May 20, 2004.

FIG. 2B illustrates a snapshot of a shared memory area 92, which includes multiple entities being shared by a set of VMs (e.g., the VMs 100, 200, and 400). The shared entities include several entities that are directly referenced by the VMs (e.g., the shared entities 110, 210, and 410). The entities that are directly referenced by one or more of the VMs can be thought of as forming a “root set” of shared entities.

The shared entities that are directly referenced by the VMs may themselves reference other shared entities (e.g., the shared entities 117 and 119). The latter shared entities can be thought of as being indirectly referenced by the VMs, since there are one or more predecessor entities in the chain of references from the VMs to those entities.

Finally, the shared entities in the shared memory area 92 also include a number of entities that are not currently referenced, either directly or indirectly, by any VM (e.g., the entities 11, 13, and 15). It is these entities, which are not reachable by any sequence of references from the root set of shared entities, which can be deemed no longer used and which can thus be garbage collected.

The creation and use of shared closures, which are shown in FIG. 2A, can be realized by sample processes 350 and 450 illustrated in FIGS. 3 and 4.

The process 350 depicts an example process that can be used to create a shared closure. In the process 350, an identification of an initial entity in a first runtime system (e.g., a VM) is received (352). A shared closure—i.e., the initial entity plus the transitive closure of all the entities that are referenced by the initial entity—is then identified (354), and a determination is made regarding whether the shared closure can be used in or shared by another runtime system (e.g., another VM) (356). This determination can be made, for example, by determining whether the entities in the shared closure are shareable (or more precisely, by determining whether each object instance in the shared closure is a shareable object instance).

If the shared closure is not usable in another runtime system (“no” branch of decision 358), the process 350 raises an exception or generates some type of negative indication. For example, if the entities in the shared closure are not all shareable entity instances, the process can raise an exception to indicate that the initial entity and its shared closure are not shareable.

If the shared closure is usable in other runtime systems (“yes” branch of decision 358), the process 350 invokes a mechanism to make the shared closure available to the other runtime systems. For example, if entities are shared through the use of shared memory, the shared closure can be copied to a shared memory area (362). In that example, if a VM stores the shared closure in a shared memory area, the VM can know the address of the shared closure. If the VM stores the entities in a shared closure in consecutive entries according to addresses, the VM can now the starting address and ending address of the entities in a shared closure, and thus, know the bounds of the shared closure. In other implementations, the shared closure can be transmitted to one or more runtime systems (e.g., other VMs) through the use of messages or other means of communication.

The process of creating a shared closure can also involve associating a specified name or other identifier with the shared closure (364). Such an identifier can subsequently be used by other runtime systems to identify the shared closure to be accessed.

In some implementations, the process of creating a shared closure also involves the use of versioning. In the process 350, versioning is accomplished through the use of version numbers that are associated with the shared closures stored in shared memory. When a shared closure is created with a given name, a determination is made regarding whether a shared closure with that name already exists in shared memory. If such a shared closure does exit (“yes” branch of decision 366), the current version number associated with the shared closure is increased (368), and the new current version number is associated with the newly created shared closure (372). If there is no shared closure with the given name in shared memory (“no” branch of decision 366), the current version number for the new shared closure is set to a number that indicates a first version (e.g., 0 or 1) (370), and associated with the newly created shared closure (372).

Versioning can be used to update shared closures—e.g., a new, updated version of a shared closure can be created under the same name previously given to the shared closure. In one implementation, when a new version of a named shared closure is created, all subsequent operations to associate the named shared closure with a VM use the new version of the shared closure. VMs that are already accessing the shared closure (e.g., VMs that have a previous version of the shared closure mapped into their address space) are not affected by the new version—they simply keep all entity references to the old version. In this implementation, multiple versions of a shared closure can coexist in shared memory until the obsolete versions are no longer referenced by any VM and thus can be garbage collected.

As part of creating a shared closure, properties of the shared closure can be stored in, for example, a hashmap that has key/value pairs corresponding to identifiers of shared closures of entities and meta information for each shared closure. The meta information can include properties such as an amount of memory a shared closure consumes and the starting address of the shared closure. These properties can be determined as part of the process of creating a shared closure. The size of each shared closure can be determined because, as a runtime system creates a shared closure in shared memory, the runtime system must allocate memory for the shared closure (at the OS level) and place the shared closure in shared memory. Different techniques can be used to determine the size of a shared closure. The size of a shared closure can be determined in one example implementation based on the starting and ending addresses that define the bounds of the shared closure, if the entities in the shared closure are stored in contiguous memory (e.g., determined by subtracting the starting address from the ending address). In another example implementation, as the memory is dynamically allocated for entities in a shared closure, the size of the entities and components of entities (e.g., primitives in an object) can be tracked to determine the total size of a shared closure of entities.

FIG. 4 illustrates a flowchart of a sample process for accessing and using a shared closure. In the process 450, a name or other identifier is received (452) and used to identify an associated shared closure (454). The name or other identifier corresponds to the identifier that was associated with the shared closure when the shared closure was created (e.g., in the operation 364 in the process 350). Where versioning is implemented, if more than one version of a specified shared closure exists, the most recently created version of the specified shared closure is identified.

The identified shared closure is then associated with a runtime system (e.g., a VM) (456). In one implementation, a shared closure can be associated with a runtime system in one of two ways—either by mapping the shared closure from a shared memory area into the address space of the runtime system, or by copying the shared closure from the shared memory area into the address space of the runtime system. After the shared closure has been associated with the runtime system, the entities within the shared closure can be accessed using normal operations (e.g., normal Java operations) (462).

In some implementations, access to the entities in a shared closure may depend on how the shared closure is associated with the runtime system. For example, in one implementation, if a shared closure is mapped into the address space of a VM (“mapped” branch of decision 458), access to the entities in the shared closure is restricted to read-only access (460). Because of this restriction, any attempt to write to a member variable of an entity instance in the shared closure will result in an error. This restriction can be useful to prevent VMs from “breaking” shared entity instances by, for example, overwriting a reference member variable in a shared object instance with a reference into a VM's private heap, or otherwise breaking the internal consistency or functionality of the shared entities.

If, on the other hand, a shared closure is copied into the address space of a VM (“copied” branch of decision 458), the VM is granted full read-write access to the copied entities. In such an implementation, the entities in a shared closure can thus be updated by copying the shared closure into the address space of a VM, modifying the content of the entities in the shared closure, and then creating a new version of the shared closure in shared memory (e.g., using the process 350 shown in FIG. 3).

Other approaches can be used to associate a shared closure with a runtime system and to provide access to the entities in the shared closure from the runtime system. For example, a copy-on-demand approach can be used. In one such implementation, a shared closure is mapped into the address space of a VM without restricting access to the shared closure to read-only access. Instead, access to the shared closure is monitored, and, upon detecting the first attempted write access to the shared closure, the shared closure is copied into the address space of the VM, thereby transforming the shared closure from a mapped shared closure into a copied shared closure. The attempted write access is then allowed to complete, and subsequent read and write accesses to the copied shared closure can proceed as they would normally. If the heap address of a shared closure changes when the transformation from a mapped shared closure to a copied shared closure occurs, existing references to the heap have to be redirected to the newly created copy of the shared closure. Alternatively, underlying OS (operating system) features can be used to map a shared closure in a manner that allows the OS to provide copy-on-demand functionality without heap address changes.

In addition to functions for creating, mapping, and copying shared closures; an Application Programming Interface (API) can include additional functions for managing shared entities. For example, an API can also include a “delete” function. One implementation of a “delete” function takes a name or other identifier as an input parameter, and marks the associated shared closure in shared memory as being deleted. Marking a shared closure as deleted does not affect VMs that are already accessing the shared closure, but VMs that subsequently try to access the shared closure (e.g., by mapping or copying the shared closure into their address spaces) are precluded from doing so.

In an implementation of a server (e.g., the server 80) in which shared closures can be mapped into the address spaces of VMs, garbage collection for deleted or obsolete versions of shared closures can be performed by keeping track of the number of VMs that have a shared closure mapped into their address space. A count can be incremented each time a VM maps a shared closure into its address space. The count can be decremented when, in the course of its own garbage collection, a VM determines that it no longer includes any references into the previously mapped shared closure. When the count associated with a particular shared closure reaches zero, that shared closure can be deleted from shared memory.

In Java, an object instance typically includes a reference to a runtime representation of the class of the object instance, and the class runtime representation in turn contains a reference to a class loader for the class. Consequently, the runtime representation and the class loader associated with a Java object instance are included in the shared closure of the object instance, which means that the runtime representation and the class loader must themselves be shareable in order for the object instance to be shareable. Thus, in a server implementation that includes class runtime representations and class loaders, two additional criteria can be used to determine whether a particular class is shareable: The class should have a shareable runtime representation and a shareable class loader. Various techniques can be used to deal with class runtime representations and class loaders (i.e., to make class runtime representations and class loaders “shareable”) and can be found in U.S. patent application Ser. No. 10/851,795, entitled “Sharing Objects in Runtime Systems,” filed on May 20, 2004.

The manner in which the shared closure is associated with the VM depends on the type of access needed by the VM. As indicated above, in one implementation, mapped shared closures are restricted to read-only access, so as to prevent a mapping VM from breaking a shared object instance in the shared closure by setting a member variable to a value that is not valid in other VMs. In such an implementation, if the VM associated with the user session only needs read access to the entities (i.e., if the VM does not need to modify any of the entities in the shared closure), the shared entities can be mapped into the address space of the selected process. The VM can then process the request, reading information from the shared entities as necessary.

If the VM needs read-write access to the shared entities (i.e., if the VM needs to modify one or more of the entities), the shared closure can be copied into the address space of a process. The VM can then have full read-write access to the shared entities, and it can process the request and modify the entities as necessary. When the VM is finished modifying the shared entities, the VM can copy the shared closure back to shared memory. As indicated previously, in one implementation, a shared closure can be copied to shared memory by re-creating the shared closure (e.g., by invoking a “create” function, assigning the same previously used name to the shared closure, and generating a new version of the shared closure if an old version of the shared closure with that name still exists in shared memory). The entities in the shared closure can include any type of entity, including entities that store user context information.

A Centralized Cache

A runtime system may include a cache, which is a temporary storage, in a memory, for entities accessed by application programs running in the runtime system. The memory used for a cache can be volatile memory of a computer system, a storage device, a database, or another type of memory in which entities to be cached can be stored. Temporary storage in a cache implies that entities put in a cache are not expected to remain in the cache. For example, after an entity is put in a cache, if at a later point in time an access of the cache is made in response to a request to retrieve that entity, the entity might not exist in the cache and the requestor might not have been notified when the entity was removed from the cache.

A data source can be chosen for a cache such that an entity in the cache can be accessed quicker from the cache than from another source (e.g., a source from which the entity originated). For example, a cache may be volatile memory in a server computer system (e.g., main memory) and an entity may originate from a storage device (e.g., a hard disk drive). In that example, the entity should be accessed quicker from the cache than from the original source, as entities typically can be accessed quicker from volatile memory than storage devices.

A cache framework can manage many aspects of a cache, such as storing entities in the cache, retrieving entities from the cache, evicting entities in the cache, and the like. A cache, and in particular a cache framework, can be accessed by a request from an application in a runtime system or by a request from the runtime system itself (e.g., if the runtime system automatically uses the cache as a redundant storage to have quicker access to entities).

Not all runtime systems have a cache, for example, the Java VM does not have a cache as a standard part of the VM, nor is it part of the Java specification. Rather, implementers of a VM must implement a cache. In an example implementation, there can be one cache per a VM and the cache can be part of the heap of the VM (i.e., part of the dynamic memory allocated and/or used by the VM). The cache can be implemented such that an application can access the cache through an application programming interface (API). API calls can include put( ) and get( ), where put( ) is an API call to put an entity in the cache and get( ) is an API call to retrieve an entity from the cache.

A cache can be implemented as a shared cache, such that cached entities can be shared across multiple VMs. For example, a cached entity may be accessed by one runtime system, modified by that runtime system, and then the modified version of the cached entity may be retrieved by another runtime system. Some implementations of a shared cache can have a centralized shared area for sharing cached entities. Advantageously, a centralized shared cache can reduce administration costs of caches on a client/server system that would otherwise have multiple caches for multiple runtime systems. In addition, resources usage, such as processing time and memory consumption, can be reduced. As an example, several entities need not be in multiple caches across a server landscape of runtime systems if a centralized cache is used, thus, memory consumption can be reduced. As another example, objects need not be updated across a server landscape if a centralized cache is used, thus, processing time can be reduced.

FIG. 5 is an illustration of a system landscape including multiple VMs 501, 502, and 503, a centralized shared memory 520, and a shared cache framework manager 530. In FIG. 5, the VMs (501, 502, and 503) are process-attachable VMs. In a server where VMs are process-attachable, each user session is provided with its own VM in order to isolate user sessions from each other and thereby increase the robustness of the system. More specifically, each user session can be provided with its own process-attachable virtual machine (PAVM), which is a VM that can be attached to and detached from an OS process. A process-attachable VM is instantiated and used for each user session—for example, VM 501 is instantiated and used for user session 1, and VM 502 is instantiated and used for user session 2. In general, a server, in one implementation, can have U user sessions, and X PAVMs. This is shown in FIG. 5 by VM 503, which corresponds to user session U.

In operation, when a server receives a request, a special process (e.g., a dispatcher process) dispatches the request to one of the available work processes in a pool of work process. Assuming that the request corresponds to user session 1 (which in turn corresponds to the VM 501), and that the dispatcher process dispatches the request to work process 511, the server attaches or binds the VM 501 to work process 511 in order to process the request. After the request has been processed, the server can detach VM 501 from the work process 511. Work process 511 can then be used to process another request. For example, if the server receives a new request that corresponds to user session 2, and the dispatcher process dispatches that request to the work process 511, the corresponding VM 503 can be attached to the work process 511 to process the new request. Continuing with this example, if the server receives another request corresponding to user session 1 while work process 511 is still being used to process the request corresponding to user session 2, the dispatcher process can dispatch the new request from user session 1 to work process 513, and the VM 501 for user session 1 can be attached to the work process 513 in order to process the new request from user session 1. A server need not have a dispatcher process. For example, in an alternative implementation, user requests can be serially assigned to processes allocated to the server. Each process could maintain a queue of requests, and attach the process-attachable VM of the user session corresponding to the request at a front of the queue in order to process that request. Although the VMs depicted in FIG. 5 that use the centralized, shared cache framework are PAVMs, in alternative implementations, the VMs need not be process-attachable.

In FIG. 5, a cache includes the centralized shared memory 520 and the shared cache framework manager 530. The centralized shared memory 520 is operable to store entities for the shared cache framework manager 530. The shared cache memory 520 can be implemented as main memory of a computer system (e.g., RAM), a storage device (e.g., a hard disk drive), a database, or any other suitable mechanism. The cache memory can be accessed via a plug-interface (referred to as a storage plug-in) such that different types of memories can be used for the cache memory. Entities that can be cached can come from many different types of memory, such as a database, a storage device, main memory, and the like. The source of entities can be accessed via a plug-in referred to as a data source plug-in. In general, memory is shared if multiple processes and/or threads can access a same entity in the memory. The centralized shared memory 520 is a shared memory such that entities in the memory 520 do not have an affinity to any of the VMs (501, 502, or 503) or any of the work processes (511, 512, or 513), and the memory can be accessed by any of the VMs (501, 502, or 503). Cached entities in the shared memory can be part of the heap (i.e., dynamically allocated portion of memory) of one or more of the VMs (501, 502, or 503).

In some implementations, the shared cache framework manager 530 can access the cache by interfacing with the memory 520 via a plug-in, referred to as a storage plug-in. In those implementations, each type of memory that can be used as a cache memory (e.g.s, database, storage device (e.g., hard disk drive), main memory (e.g., local heap), and the like) can be accessed via a storage plug-in. Thus, multiple types of memory can be accessed easily, alone or in combination, by different storage plug-ins. Because there is a standardized interface provided by a plug-in interface, the type of memory can be changed easily. The storage plug-in, in addition to defining the type of media, can define how the items are stored. For example, there can be two storage plug-ins, one for mappable shared closures (i.e., shared closures that can be mapped and, in some implementations, copied) and one for copy-only shared closures (i.e., shared closures that can only be copied).

The shared cache framework manager 530 includes an API 531 and a cache entry table 532. API calls to the shared cache framework manager 530 are received via the API 531. In other words, applications can include code to cache entities in the cache. API calls can include, a request for a measurement of the amount of memory used by the centralized shared memory 520, a request to retrieve one or more entities in the centralized shared memory 520 (e.g., a get( )), a request to store one or more entities in the centralized shared memory 520 (e.g., a put( )) and a request to remove one or more entities in the cache (e.g., a remove( )). Thus, for example, an application can include a put( ) call, where an entity is stored in the cache, and the application can later attempt to access the cached entity via a geto call. If the entity no longer exists in the cache (e.g., the entity was explicitly removed by an application or an eviction policy caused the entity to be removed), an error message can be returned; otherwise, the cached entity can be returned to the application.

The shared cache framework manager 530 manages the cache entry table 532. The cache entry table 532 indicates whether an entity is in the cache and indicates locations of entities in the cache (i.e., locations within the centralized shared memory 520). Any type of data structure can be used to implement the cache entry table 532. In one example implementation, a set of hash maps (i.e., a data structure that maps keys to values) is used as the cache entry table 532. In that example, hash codes can be generated based on a chosen key for an entity (e.g., a name of the entity). The set of hash maps can include one hash map for the location of a cached entity and other hash maps for properties of cached entities. In that way, properties can be edited without having to retrieve a cached entity (in contrast to, for example, having properties included with a cached entity). In the first hash map, a hashed entry (i.e., a hash code) can be associated with an indication of the location of the entity in a shared memory (e.g., a pointer). Another hash map can include an association of the hashed entry with an indication as to whether the item is locked (e.g., cached entries can be locked if it is decided that concurrent access to a cached entity should not be granted). And, another hash map can include an association of the hashed entry with an indication of the size of a cached entity (e.g., the size of a shared closure of entities). Thus, for example, the name of an entity can be sued by the cache framework manager 530 to access a cached entity by and/or modify entries in the cache entry table 532 that correspond to entities stored in the centralized shared memory 520. Alternative implementations of a cache system can use mechanisms and/or techniques other than the cache entry table 532 to manage cached entities.

In alternative implementations, the cache framework manager 530 need not have an API. For example, applications can interface with the centralized cache using other techniques and/or mechanisms, which might include manually accessing the cache entry table 532 from applications, applications managing the cache entry table, and applications directly accessing the centralized shared memory 520.

The centralized shared memory 520 includes shared closures of entities 521, 522, and 523. Shared closures of entities (as described earlier) allow some entities to be shared across runtime systems that would otherwise not be shareable. For example, objects that include references to other objects might not be shareable across runtime systems as they can have references and the like that represent an affinity between a virtual machine and the objects. Shared closures of entities overcome this obstacle by including the transitive closure of all entities such that entities, such as Java objects, can be shared across runtime systems and the affinity between an object and a local heap, can be removed.

In operation, the cache system depicted in FIG. 5, including the shared cache framework manager 530 and the centralized shared memory 520, is a centralized shared cache system. The system is centralized such that each of the VMs 501, 502, and 503 can access a single copy of a cached entity. For example, an application running in the VM 501 can cause a first shared closure of entities 522 to be cached in the centralized shared memory 520. Then, any of the VMs can access the shared closure of entities 522. For example, as depicted in FIG. 5, the dotted lines 540 illustrate that both an application running on the VM 501 and an application running on the VM 502 are accessing the shared closure of entities 522 concurrently. Although in FIG. 5, the lines 540 depict that the shared closure of entities 522 can be accessed by two VMs concurrently, in some implementations, entities in a cache might not be accessible concurrently.

In some implementations, the cache need not be the only type of heap available to a runtime system. For example, other types of dynamically allocated memory, such as a local non-cached heap, can be used in addition to a cache. In some implementations, different scopes can be provided for different runtime and/or computer system configurations. For example, an application may have a choice of a scope of caching entities. The scope can include a centralized shared cache for a single computer system (e.g., a single server), or sharing an entity in a shared cache across a cluster of computer systems (e.g., a cluster of servers). In combination with a non-shared cache, an application can have an ability to choose three scopes of caching entities including, local heap non-shared cache, single-computer system shared cache, or cluster-wide shared cache. As such, one or more centralized shared caches can be implemented in conjunction with a non-shared cache. For example, in one implementation, a runtime system can have a local cache (i.e., non-shared, not centralized), each computer system on which multiple runtime systems can run can have a centralized shared cache system (e.g., a centralized cache per a server), and a centralized shared cache system can be implemented for a cluster of computer system including each of the computer systems with a centralized shared cache limited in scope to the computer system (e.g., a centralized cache per a cluster of servers).

FIG. 6 is a flowchart of a process of responding to a user request to store an entity in a cache. The process starts when a request is received to store an entity in the cache (610). An entity can be, for example, a string, a constant, a variable, an object instance, a class runtime representation, or a class loader. In some implementations, the entities can only be shared closures of entities to ensure shareability of entities in a cache. The request can be received at a cache framework manager, such as the cache framework manager 530. The request can be generated by an application running at a runtime system or by a runtime system itself (e.g., if a runtime system automatically caches entities redundantly). If the cache framework redundantly caches entities, a plug-in referred to as a data source plug-in can be used and that plug-in can facilitate redundant caching of entities. For example, the plug-in can correspond to a persistent storage device (e.g., a hard disk drive) and the plug-in can be used to interface with the storage device such that entities from the storage device are automatically redundantly stored when they are pulled from the storage device. The request can be in the form of an API call. For example, in Java VM cache implementations, an application can make an API call known as put( ), to request that an entity is added to a cache.

In response to the request, the entity can be stored in a cache memory (620). For example, an entity can be stored in the centralized shared memory 520. Storing an entity can involve determining the shared closure of an entity requested to be stored (i.e., determining the transitive closure of entities), and storing the shared closure of entities. Storing shared closures of entities, rather than simply storing an entity (regardless of determining whether there are any references to another entity in that entity) can ensure that entities are shareable (conditions for determining if an entity is shareable and techniques for making an entity shareable are described in more detail). The type of cache memory can be chosen by a specified storage plug-in (as described earlier). For example, storage plug-ins for a cache framework can include a mappable or copy-only shared closure plug-in.

An entry for the entity can be created in a cache table (630), such as the cache entry table 532. Creating the entry can include storing in a hash map an entry that indicates the location of the entity. In addition, it can involve storing properties of the entity. In response to a determination that the entity (i.e., the entity that was requested to be stored) is to be mapped, the entity is stored and an indication that the entity is to be read-only is made (630). In alternative implementations a mapped entity need not be limited to read-only access.

Once an entity is stored in a memory and a cache framework of a cache system has an entry that corresponds to the entity (i.e., once the entity is cached), the entity can be retrieved.

FIG. 7 is a flowchart of a process of responding to a user request to retrieve an entity from a cache. A request is received to retrieve an entity from the cache (i.e., an entity that might be in the cache) (710). An entity can be, for example, a string, a constant, a variable, an object instance, a class runtime representation, or a class loader. The request can be received at a cache framework manager, such as the cache framework manager 530. The request can be generated by an application running at a runtime system or by a runtime system itself (e.g., if a runtime system automatically caches entities redundantly—i.e., redundant to a data source that can be used to retrieve the entities, such as a data source accessible via a data source plug-in). The request can be in the form of an API call. For example, in Java VM cache implementations, an application can make an API call known as get( ), to request that an entity is retrieved from a cache.

In response to the request to retrieve an entity from the cache, a determination is made as to whether the entity exists in the cache (720). In some implementations, the determination can be made by a cache framework, or more particularly, a cache framework manager of a cache framework. For example, a determination can be made by the cache framework manager 530 of FIG. 5. Determining whether the entity exists in the cache can involve looking up a cache entry in a cache entry table. For example, the cache framework manager 530 can use the cache entry table 532 to determine, based on an identification of the entity (e.g., a key), whether the entity exists in the centralized shared memory 520. If the entity is not in the cache, a message is returned indicating that the requested entity was not found (i.e., the entity does not exist in the cache) (730). The message can be an error message. In alternative implementations, a cache system can perform other appropriate actions. For example, an exception can be raised. Also, in some implementations, no action can be taken.

If the entity was found in the cache (e.g., a cache entry in a cache entry table indicates the entity is stored in a memory), a determination is made as to whether the entity should be mapped or copied (740). If mappable shared closures are chosen to implement the cache, the entity can be mapped or copied depending on a request. For example, a function for retrieving entities from the cache can include two arguments (i.e., get(argument1, argument2)). The first argument can be used to indicate the entity to be retrieved and the second argument can be used to indicate whether a shared closure should be mapped or copied. A program can decide to copy a shared closure if the shared closure is expected to be modified. That decision can then be included in the second argument.

The choice between mapping and copying shared entities can be used to increase performance of the cache by having alternative mechanisms for retrieving entities, where each mechanism is optimized for a type of retrieval. For example, resource consumption can be reduced as mapping a shared closure can be less resource consumptive than copying cached entities to a local heap and some entities need not be copied and those entities can be mapped. In addition, the approach can provide flexibility, as entities in a centralized shared cache can be changed. Also, if locks are implemented, the approach can prevent destructive interaction between runtime systems accessing the same entity by ensuring that cached entities that can be modified are not concurrently accessed.

In alternative implementations, the determination of 740 might not be made. For example, if copy-only shared closures are implemented (e.g., a storage plug-in for copy-only shared closures is used), shared closures are only copied (as mapping of shared closures is not provided). In alternative implementations the type of entities and/or mechanisms for retrieving entities can differ.

Returning to the flowchart of FIG. 7, if the cached entity is to be mapped, then read-only access is granted and a mechanism returns a mapping of the requested entity to the requester of the entity (750).

If the cached entity is to be copied, then a determination is made as to whether the requested entity is being used (760). The requested entity is in use if another runtime system is accessing the entity. The cache system implementing the process depicted in the flowchart of FIG. 7 can implement locks. Thus, the determination at 760 can be made by determining whether the requested entity is locked. An indication as to whether an entity is locked can be in the cache entry of a cache entry table, such as the cache entry table 532. If the requested entity is being used, the requestor can wait for the requested entity to become available (770). For example, if the requestor was a thread, the thread can yield.

If the requested entity is available, a copy of the requested entity is returned to the requestor (780). Returning a copy of the requested entity includes providing copy access to the entity such that the entity can be changed.

Although not depicted in the flowchart, versioning of cached entities can be implemented (as described above in reference to versioning of shared closures in a shared memory). By allowing versioning of cached entities, multiple copies of a cached entity can be worked on without having to worry about changes being made to a copy that is being worked on. Versioning of cached entities can be limited such that creating versions of entities does not consume too many resources. For example, versioning can be limited to entities that are not expected to be updated frequently (e.g., by choice of a programmer). Versioning of entities can include mapping entities and, if an entity is to be updated, generating an updated version that is also cached (such that entities that are mapped can also be changed). When the older version is no longer referenced, that version can be removed and the updated version can be mapped in future requests to retrieve that entity.

The cache system of FIG. 5 and the processes of FIGS. 6 and 7 can be implemented in a suitable server that runs in a client/server configuration, such as a J2EE compatible server. An example of such a server is the Web Application Server developed by SAP.

Eviction In Caches

Eviction of cached entities can be implemented in a cache system including a centralized shared cache. Once an entity is evicted from cache, the entity is no longer accessible. Typically, cached entities are evicted according to an eviction policy. Processes (i.e., techniques) for evicting cached entities can be based on a fill level of a cache (i.e., how full a cache is or, rather, how much is in the cache).

The fill level of the cache can be measured according to one or more fill metrics (i.e., one or more metrics can be used to compute the fill level of the cache). For example, a fill level can be calculated based on a fill metric corresponding to an overall amount of memory consumed by a cache. As another example, a fill level can be calculated based on a fill metric corresponding to an overall amount of entities in a cache. For multiple fill metrics, measurements corresponding to the fill metrics can represent the fill level. Each fill metric has an associated threshold and any combination of the thresholds can be used to determine that a threshold for a fill level of a cache has been reached. For example, in one implementation, a threshold for the fill level of the cache can be reached only if measurements corresponding to each of two metrics both exceed an associated threshold (i.e., measurements for both fill metrics are greater than their respective thresholds). In another implementation, a threshold for the fill level of the cache can be reached if either of two measurements corresponding to each of two metrics exceeds an associated threshold (i.e., measurements for only one of the fill metrics need be above a respective threshold). In that example, two fill metrics can be size of the cache and amount of entities in the cache; measurements for the fill metrics can be 30 megabytes and 1020 entities, respectively; thresholds associated with the fill metrics can be 50 megabytes and 1000 entities, respectively. Because the threshold for the cache is reached when either fill metric reaches an associated threshold, the threshold for the cache would be reached because a measurement for the amount of entities (i.e., a fill metric) has exceeded the associated threshold (i.e., the threshold for the amount of entities being 1000, and 1020 entities being greater than 1000 entities).

Based on a fill level of a cache, one or more actions can be performed in a cache system. As described above, processes (i.e., techniques) for evicting cached entities can be implemented such that the processes are activated based on a fill level. For example, if a fill level is above a first threshold, a process of eviction that actively evicts cached entities can be initiated. In a cache that has multiple fill metrics where each metric has a different amount of associated thresholds, suitable techniques can be used to determine a combination of exceeded thresholds to determine whether a threshold of a cache has been reached and which processes should be performed. For example, in one implementation, two fill metrics can be amount of entities in a cache and size of the cache, and the fill metrics can have three and two associated thresholds, respectively. In that implementation, one threshold of the cache can be reached when a first of two thresholds is exceeded for the amount of entities in the cache and a first of two thresholds is exceeded for the size of the cache; and a second threshold of the cache can be exceeded when a second of two thresholds is exceeded for the amount of entities in the cache and the first of two thresholds is exceeded for the size of the cache. When the first threshold of the cache is exceeded, a first process can be performed and when the second threshold of the cache is exceeded, a second, distinct process can be performed. Thus, different combinations of thresholds associated with fill metrics can be used as thresholds for performing different actions.

FIG. 5 includes an example system in which eviction of cached entities can be implemented. The eviction of cached entities can be managed by the shared cache framework manager 530. In some implementations, the shared cache framework manager 530 can evict cached entities in accordance with a policy (i.e., an eviction policy).

A cache system can use plug-ins to implement different eviction policies in a cache system. For example, a cache system can have an eviction plug-in corresponding to an eviction policy that approximates a least recently used policy. By interfacing the plug-in with the cache system (e.g., copying the policy to a file system and setting environment variables for a server that implements the centralized cache framework), the plug-in can be used by the cache system. Because plug-ins can be used (as opposed to, e.g., hard-coding), eviction policies can be detached easily from a cache system and new eviction policies can be implemented easily, with little or not effort. Each plug-in can contain a specification of a different eviction policy.

Different techniques can be used to implement eviction policies as plug-ins. For example, an eviction policy plug-in can include executable instructions (e.g., compiled source code) that represent a process of indicating which cached entity should be evicted. As another example, a plug-in can interface with the shared cache framework 530 and/or the cache entry table 532 via the API 531, such that the plug-in can view cache entries and, based on certain rules and/or calculations, determine which cached entity should be evicted, and cause that entity to be evicted by an API call. A plug-in can act like a black box such that, when called, the plug-in returns an indication of a cached entry that should be evicted. As a black box, the plug-in can be designed to fulfill certain implementation details such that the plug-in properly interfaces with a cache system.

Although FIG. 5 includes a centralized shared cache, implementations of the eviction processes and mechanisms that evict cached entities need not be implemented in such a cache. For example, a non-shared cache can be implemented that determines a fill level of a cache based on multiple fill metrics. As another example, a cache need not be implemented such that multiple fill metrics are used. For example, in one implementation only the size of the cache is used as a fill metric.

FIG. 8 is an illustration corresponding to a cache system in which multiple thresholds are associated with multiple fill metrics. FIG. 8 includes a graph 810 corresponding to a fill metric for an amount of entities in a cache and a graph 820 corresponding to a size of the cache. The graph 810 includes a measured level 811 (i.e., the fill level of the cache according to the metric for an amount of entities) and three thresholds 812, 813, and 814. The measured level 811 can be measured by any suitable technique. One technique, can involve counting a number of cache entries in a cache entry table. Measurements can occur periodically or in response to events. For example, a measurement can be taken after a request to store an entity in the cache, but before the entity is stored in the cache. In a runtime system that includes dead and live entities, such that garbage collection can be required before entities are removed, the measured level 811 can include both dead and live entities, or the measured level 811 can include only live entities.

The graph 810 corresponds to a cache system in which a fill metric for the amount of entities in a cache is associated with three thresholds. When each of those three thresholds is exceeded, a distinct eviction process starts. The processes can overlap, or the processes can be mutually exclusive. For example, if the first threshold 812 is exceeded, a first process can start. Then, if the second threshold 813 is exceeded, a second process can start and that process can run at the same time as the first process. As another example, a first process can start in response to the first threshold being exceeded, then, when the second threshold is exceeded the first process can be halted and a second process can start. If multiple processes are associated with multiple thresholds, one or more processes can overlap or be mutually exclusive.

Until the first threshold is reached, no eviction process is running (however, other processes that can reduce the fill level, such as garbage collection, can run). When the first threshold 812 is exceeded, a background eviction process starts. The background eviction process evicts cached entities in accordance with an eviction policy. One example eviction policy can approximate a least recently used policy. The eviction policy approximates a least recently used policy, as the policy is not guaranteed to evict the least recently used cached entity. The eviction policy can approximate, rather accurately model, a least recently used process because sorting a list of cached entities to accurately determine a least recently used cached entity can be resource consumptive, so sorting might not occur often. Alternatively, any eviction policy can be used.

The background eviction process continues until enough cached entities have been evicted such that measured level 811 is below the first threshold 812. The background eviction process runs in the background. Running in the background can involve the background eviction process only running (e.g., attempting to evict cached entities) when the cache system would otherwise be idle; running when runtime systems that access the cache are idle; running in between accesses to the cache; or at other suitable times such that the background eviction process does not significantly interfere with the performance of the cache system. As a background process, the time consumption for evicting cached entities is not prescribed to a user request.

If the second threshold 813 is exceeded, a second, distinct eviction process starts (i.e., distinct from the first eviction process). The second eviction process actively evicts cached entities in accordance with the eviction policy. When the second process starts, the background process of eviction stops. By stopping background eviction, double eviction can be avoided and resource usage can be optimized. Actively evicting cached entities can involve, for example, continually evicting entities until the fill level drops below the second threshold. In contrast to background eviction, time consumption for evicting cached entities in prescribed to a user request (i.e., the time consumption of a requests to store an entity in the cache includes the amount of time consumed to evict an entity from the cache). The second eviction process runs until the measured fill level 811 goes below the second threshold 813, at which point the first eviction process can start again.

If the measured level 811 is to exceed the third threshold 814, a third process starts in response to that request. The third process denies any request to add an entity to the cache. For example, if an application requests to add an entity, that entity can only be added to the cache as a shared closure that includes 12 entities, the cache has 998 entities, and the third threshold 814 represents 1000 entities, adding that entity would cause the measured level 811 to exceed the third threshold 814 (i.e., 998+12>1000). Thus, the entity is not added to the cache. The third threshold 814 acts as a hard boundary by declining requests to add an entity to the cache. As described above, the technique of determining whether the third threshold is exceeded differs from the technique used to determine whether the other thresholds have been exceeded. The determination as to whether the third threshold 814 has been exceeded is made prospectively, before an entity is added to the cache, whereas the determinations corresponding to the first and second thresholds 812 and 813 are made after an entity is already added to a cache. In alternative implementations the determinations can all be prospective, or there can be any combination.

Multiple thresholds corresponding to multiple processes can be implemented to optimize cache eviction by balancing cache requests and resource usage. Because the first threshold 812 is used to start background eviction, requests to cache entities need not be hindered by the eviction processes in the cache. Thus, user requests are quickly satisfied in lieu of memory resources. When the memory resources are sufficiently consumed (i.e., when the second threshold is exceeded), active eviction starts, which can ensure the cache does not get too large while still enabling entities to be cached. The hard boundary corresponding to the third threshold can ensure that the cache never exceeds usage of memory resources that might be at a critical level.

In contrast to graph 810, the graph 820 includes two thresholds 822 and 823. The first threshold 822 corresponds to a process of background eviction (i.e., the second process described above in reference to the first threshold 812), and the second threshold 823 corresponds to a process of declining requests to store entities in the cache (i.e., the process described above in reference to the third threshold 814). The graph 820 corresponds to a fill metric for the size of cache memory used. Measured level 821 corresponds to the fill level of the cache for that fill metric.

Graph 820 can correspond to a different cache system than the cache system that corresponds to graph 810. Or, the two can correspond to a same cache system. For example, because the first threshold 812 of the graph 810 corresponds to a process for background eviction of cached entities and the first threshold 822 of graph 820 corresponds to a process for background eviction of cached entities, if either threshold (i.e., 812 or 822) (or, alternatively only if both) is exceeded, a process of background eviction of cached entities can start. Although the fill metrics depicted in the graph 810 and the graph 820 have different numbers of thresholds (i.e., three and two, respectively), in alternative implementations two fill metrics can have a same number of thresholds. In those implementations, a combination of the thresholds can similarly be used to determine which processes for evicting cache should start, and when.

FIG. 9 is a flowchart of a process 900 of evicting cached entries. At 905, a determination is made as to whether a request to add an entity to the cache has been received. This request can be received, for example, at a cache framework that manages a cache and cache eviction. If a request has not been received, the determination is repeated (905).

If a request has been received to add an entity to a cache, a determination of a fill level corresponding to a fill metric is made (910). For example, if the fill metric is an amount of entities in the cache, the fill level is a measurement of the amount of entities in the cache and can be determined by referencing a cache entry table. As another example, if the fill metric were a size of the cache, the determination could be made by adding the sum of the size of all the entities in the cache. In one implementation, all objects are added to a cache as a shared closure. In that implementation, there is a function for shared closures such that the size of a shared closure can be readily determined. Thus, the size of a cache can be determined by computing the sum of all of the shared closures in the cache, where the size of each shared closure can be computed by the function (a size for an individual shared closure can be determined, as described above).

At 915, an expected fill level of the cache is determined. The expected fill level is a calculation of how full a cache would be were the entity to be added to the cache. This determination can involve adding the determination from 910 with a determination as to how the entity would affect the fill level of the cache. In a cache system implementing shared closures and a shared cache, if a request is received to add an entity to the cache and the entity could only be shared if a transitive shared closure of entities that includes the entity is stored, the process at 915 can determine the expected fill level to include all entities that would be in the cache if the shared closure were added. For example, if a fill metric is a size of the cache, the size of a shared closure including the entity requested to be added to the cache can be computed and that amount can be added to the amount computed at 910 to determine an expected fill level of the cache.

At 920, a determination is made as to whether the first threshold would be exceeded were the entity to be added to the cache. If not, the entity is stored in the cache (925). In FIG. 8, a first threshold not being exceeded corresponds to the region in graph 810 under the first threshold 812. Storing the entity in the cache can include storing the entity and other entities from a shared closure to which the entity belongs.

If the first threshold would be exceeded, a determination is made as to whether the second threshold would be exceeded were the entity to be added to the cache (930). If that threshold would not be exceeded, the entity is stored in the cache and a background eviction process is started (935). The background eviction process can continue until the fill level corresponding to a fill metric goes below the first threshold. The region of the graph 810 between thresholds 812 and 813 corresponds to the first threshold being exceeded and the second level not being exceeded.

If the second threshold would be exceeded, a determination is made as to whether the third threshold would be exceeded were the entity to be added to the cache (940). If the third threshold would not be exceeded, the entity is stored in the cache and active eviction starts (945). Active eviction removes cached entities until the fill level drops below a threshold. The region of the graph 810 between thresholds 813 and 814 corresponds to the first and second thresholds being exceeded, and the third threshold not being exceeded. That is the region where active eviction would be performed,

If the third threshold would be exceeded, the request to add an entity to the cache is declined (950). Declining the request can involve returning a message to an application or raising an exception. Alternatively, a request can be declined by taking no action. After each of the processes at 925, 935, 945, and 950, the process 900 continues at 905.

Although FIG. 9 was generally described with reference to adding a single entity to a cache, FIG. 9 could be modified for adding multiple entities. As an example of a modification, in a cache system implementing shared closures and a shared cache, if a request is received to add an entity to the cache and the entity could not be shared, the request can be denied. Although FIG. 9 was described with respect to a single fill metric, the processes of FIG. 9 can be modified for using two fill metrics. Although FIG. 9 uses a serial process of determining whether a first, second, or third threshold has been exceeded (i.e., a determination for the first threshold, then a determination for the second threshold, then a determination for the third threshold), in alternative implementations other techniques can be used. Although the first, second, and third thresholds of FIG. 9 correspond to processes of background eviction, active eviction, and declining cache requests, respectively, in alternative implementations the processes corresponding to the thresholds can differ. Similarly, the amount of thresholds can vary. For example, one implementation can include four thresholds corresponding to four distinct processes. Although cache eviction was described as having a single policy per an implementation, a combination of policies can be implemented. For example, in one implementation where a fill metric has four associated thresholds corresponding to four distinct processes, a first process could perform background eviction according to an approximated least recently used policy, a second process could perform background eviction in accordance with a least recently used policy (i.e., not approximated), a third process could perform active eviction in accordance with a least recently used policy, and a fourth process can decline requests to store entities in the cache.

The disclosed subject matter and all of the functional operations described herein can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structural means disclosed in this specification and structural equivalents thereof, or in combinations of them. The disclosed subject matter can be implemented as one or more computer program products, i.e., one or more computer programs tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program (also known as a program, software, software application, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file. A program can be stored in a portion of a file that holds other programs or data, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.

The processes and logic flows described herein, including the method steps of the disclosed subject matter, can be performed by one or more programmable processors executing one or more computer programs to perform functions of the disclosed subject matter by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus of the disclosed subject matter can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry.

To provide for interaction with a user, the disclosed subject matter can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.

The disclosed subject matter can be implemented in a computing system that includes a back-end component (e.g., a data server), a middleware component (e.g., an application server), or a front-end component (e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the disclosed subject matter), or any combination of such back-end, middleware, and front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet.

The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

Although the processes of FIGS. 3, 4, 6, 7, and 9 are shown as being composed of a certain number and type of processes, different processes, additional and/or fewer processes can be used instead. For example, in alternative implementations locks might not be implemented. Thus, the process shown in FIG. 7 need not include the processes performed at 760 and 770. Similarly, the processes need not be performed in the order depicted. Thus, although a few implementations have been described in detail above, other modifications are possible. Other implementations may be within the scope of the following claims.

Claims

1. A computer program product, tangibly embodied in an information carrier, the computer program product comprising instructions operable to cause data processing apparatus to:

receive a request at a centralized shared cache framework to store an entity;

cache the entity in a shared memory in response to the request, wherein the shared memory is operable to store the entity such that the entity is accessible to a plurality of runtime systems, and caching the entity in the shared memory comprises storing the entity for one of the runtime systems;

receive a request at the centralized shared cache framework to retrieve the entity from the shared memory; and

if the entity is stored in the shared memory, retrieve the stored entity from the shared memory, wherein the centralized shared cache framework is operable to retrieve the entity for any of the runtime systems.

2. The computer program product of claim 1, wherein the instructions to cache the entity in shared memory comprise instructions to:

interface the centralized shared cache framework with a storage plug-in to store the entity in a type of memory that is associated with the storage plug-in.

3. The computer program product of claim 1, wherein the instructions to cache the entity in shared memory comprise instructions to cache a shared closure of entities.

4. The computer program product of claim 3, wherein the instructions to cache a shared closure of entities comprise instructions to:

cache versions of shared closures of entities.

5. The computer program product of claim 3, wherein the instructions to cache a shared closure of entities comprise instructions to:

cache at least two types of shared closures, the types of shared closures comprising:

a first type corresponding to shared closures being mappable; and

a second type corresponding to shared closures being copy-only.

6. The computer program product of claim 3 further comprising instructions to:

lock the second type of shared closures to prevent multiple accesses to a copy-only shared closure.

7. The computer program product of claim 3, wherein the instructions to retrieve the stored entity from the shared memory comprise instructions to:

retrieve a cached entity that is of the first type of shared closure by mapping the cached entity to a runtime system.

8. The computer program product of claim 3, wherein the instructions to retrieve the stored entity from the shared memory comprise instructions to:

retrieve a cached entity that is of the second type of shared closure by copying the cached entity to a local memory of a runtime system.

9. The computer program product of claim 1 further comprising instructions to:

determine the memory used by cached entities.

10. The computer program product of claim 1, wherein the runtime systems are virtual machines.

11. The computer program product of claim 1, wherein the runtime systems are Java virtual machines.

12. A computer program product, tangibly embodied in an information carrier, the computer program product comprising instructions operable to cause data processing apparatus to:

receive a request at a cache framework from Java virtual machines to determine an amount of memory used by the cache framework;

determine a first amount of memory used by the cache framework; and

send the first amount in response to the request.

13. A server computer system comprising:

a shared memory operable to store entities accessible to a plurality of runtime systems; and

a centralized shared cache framework operable to perform operations comprising caching entities for one of the runtime systems in the shared memory, wherein the shared cache framework stores the cached entities in the shared memory and the centralized shared cache framework enables access to the cached entities to runtime systems such that any of the runtime systems can access a same entity.

14. The system of claim 13, wherein the server computer system further comprises an interface for different cache storage plug-ins, each storage plug-in associated with a type of memory and operable to interface the type of memory with the centralized shared cache framework.

15. The system of claim 14, wherein the server computer system further comprises a cache storage plug-in operable to interface a database with the shared cache framework.

16. The system of claim 13, wherein caching entities comprises caching shared closures of entities.

17. The system of claim 16, wherein the centralized shared cache framework is further operable to determine an amount of memory consumed by cached entities.

18. The system of claim 17, wherein the centralized shared cache framework is further operable to determine the memory consumed by the cached entities based on a function operable to determine an amount of memory used by a shared closure of entities.

19. The system of claim 13, wherein the runtime systems are Java virtual machines.