Elastic caching for Java virtual machines

A mechanism is provided for managing memory of a runtime environment executing on a virtual machine. The mechanism includes an elastic cache made of objects within heap memory of the runtime environment. When the runtime environment and virtual machine are not experiencing memory pressure from a hypervisor, the objects of the elastic cache may be used to temporarily store application-level cache data from applications running within the runtime environment. When memory pressure from the hypervisor is exerted, the objects of the elastic cache are re-purposed to inflate a memory balloon within heap memory of the runtime environment.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This application is related to the patent application entitled “Hybrid In-Heap Out-of-Heap Ballooning for Java Virtual Machines” Ser. No. 13/460,565, which is assigned to the assignee of this application and have been filed on the same day as this application.

BACKGROUND

Virtual computing environments allow multiple virtual machines (VMs) to run on a single physical platform (also referred to herein as a “host”) and to share physical resources. Some virtual computing environments enable configuration of VMs such that the total amount of memory designated for use by the VMs is larger than the actual amount of memory available on the host. Referred to as memory over-commitment, this feature enables the host to support the simultaneous execution of more VMs. To achieve over-commitment, the virtual computing environment simply gives a VM less memory than what the guest operating system (OS) in the VM believes it has.

Memory over-commitment is traditionally enabled using a technique known as ballooning, which is described in U.S. Pat. No. 7,433,951, the entire contents of which are incorporated by reference herein. A balloon is a resource reservation application that runs as a guest application in the VM or as driver in the guest OS that requests guest physical memory from the guest OS. After the guest OS has allocated guest physical memory for use by the balloon application, the balloon application is able to ultimately communicate information regarding the allocated guest physical memory to a hypervisor that supports the VM, which is then able to repurpose the host's system memory (also referred to herein as “machine memory”) backing the guest physical memory allocated to the balloon application. That is, since the balloon application only reserves guest physical memory but does not actually use it, the hypervisor can, for example, repurpose machine memory that backs such allocated guest physical memory for use by another VM without fear that the balloon application would write to the guest physical memory (and therefore the backed machine memory).

Another technique for memory management that is useful under memory over-commitment situations is referred to as page sharing. In this technique, the virtual computing environment identifies and eliminates redundant copies of guest physical memory pages across VMs. The virtual infrastructure maps the identical guest physical pages to the same machine memory page and enables copy-on-write behavior with regards to that machine memory page. This technique enables sharing of memory between VMs in cases where VMs may be running instances of the same guest OS, applications, and libraries, and have other data in common.

Unfortunately, there are applications and runtime environments that do not work well with conventional memory over-commitment in virtual computing environments. Java Virtual Machine (JVM) is one of the most widely used runtime environments in this category. JVMs typically have their own memory management mechanisms. Allocated Java objects sit in a JVM heap until the JVM runs out of heap space, and in this event, garbage collection sweeps the heap and recycles dead objects, which are the objects unreachable from the program. A memory-managed JVM runtime can be a problematic candidate for memory over-commitment because freed memory made available by garbage collection is typically held exclusively for the use of the runtime and therefore cannot be used by other applications running in the operating system or virtualized infrastructure. In this environment, attempts to over-commit the memory may result in lack of memory to support the JVM heap, causing a significant performance hit.

Such issues with memory over-commitment may be further exacerbated as a result of memory usage by certain applications running within a JVM. Notably, production-level applications typically use some form of caching to increase responsiveness and performance. However, application-level caches may continue to take up space in heap memory even though the JVM and underlying VM may be experiencing memory pressure. Some caching mechanisms have used “soft referenced” objects to permit a garbage collection to reclaim space from the cache. However, in practice, some JVMs may be slow to remove soft referenced objects even though the JVM may be under memory pressure. Further, applications generally have no control over the timing and scope of a garbage collection operation. For example, applications lack control over which soft referenced objects in the cache may be removed (i.e., garbage collected) and are unable to make a distinction between “hot” cache entries and “cold” cache entries. Further, multiple garbage collection operations may be needed to fully collect a soft referenced cache. Each garbage collection may occur at an inopportune time, each time causing the JVM to pause, thereby significantly impacting performance of the JVM and applications running therein.

SUMMARY

One or more embodiments of the present disclosure provide methods, systems, and computer programs for managing memory in a host computer system in which virtual machines (VMs) execute. In one embodiment, an application executing within a runtime environment (e.g., JVM) may use an elastic cache comprised of a plurality of objects within heap memory to store cache data. A balloon agent running within JVM is configured to inflate and deflate a memory balloon with the runtime environment according to memory pressure indications provided from outside the VMs (e.g., by a hypervisor). To inflate the balloon, the balloon agent re-purposes objects (or in some cases, allocates new objects) from the elastic cache, overwrites cache data within the objects with a predetermined value, and notifies a hypervisor that memory pages containing the objects may be page-shared and reclaimed for other uses. To deflate the balloon, the balloon agent repurposes one or more of the objects under its control to be once again used in the elastic cache. Accordingly, embodiments of the present disclosure provide a memory balloon and application-level cache comprised of objects that persist within memory, reducing the number of dead objects in the JVM heap that may cause garbage collection that impacts performance of application running within the JVM.

A method for managing memory of a runtime environment executing on a virtual machine, according to one embodiment, includes the steps of receiving cache data from an application executing in the runtime environment and storing the received cache data in one or more objects within heap memory of the runtime environment. The method further includes determining, by operation of a memory management agent, a target size for memory to be reserved within heap memory of the runtime environment, identifying at least one of the objects stored in the heap memory that store cache data for the application, and replacing at least some portion of the cache data stored in the identified objects with a first value. The method includes notifying a hypervisor that at least one machine physical memory page associated with the identified object and having the first value, can be re-claimed.

Further embodiments of the present invention include, without limitation, a non-transitory computer-readable storage medium that includes instructions that enable a processing unit to implement one or more of the methods set forth above or the functions of the computer system set forth above.

DETAILED DESCRIPTION

FIG. 1is a block diagram that illustrates a virtualized computer system100with which one or more embodiments of the present invention may be utilized. Computer system100(also referred to as a “server” or “host”) is configured to support a virtualized environment comprised of one or more virtual machines.

As in conventional computer systems, computer system100includes both system hardware110and system software. System hardware110generally includes a processor112, some form of memory management unit (MMU)114(which may be integrated with processor112), a disk interface116, a network interface118, and memory120(referred to herein as “machine memory”). Machine memory120stores data and software such as an operating system and currently running application programs. Generally, MMU114is responsible for managing a virtual memory for processes running in computer system100by mapping virtual memory pages to machine memory pages. MMU114typically divides virtual memory address space and machine memory address space into blocks of contiguous memory addresses referred to as memory pages122. Processor112may be a single processor, or two or more cooperating processors in a known multiprocessor arrangement. Examples of disk interface116are a host bus adapter and a network file system interface. An example of network interface118is a network adapter, also referred to as a network interface controller (NIC). In some embodiments, a plurality of NICs is included as network interface118. It should further be recognized that system hardware110also includes, or is connected to, conventional registers, interrupt handling circuitry, a clock, etc., which, for the sake of simplicity, are not shown in the figures.

One or more virtual machines (VMs), represented by VM1021to VM102N, are configured within computer system100and share the hardware resources of computer system100. Each virtual machine typically includes a guest operating system (OS)106and virtualized system hardware (not shown), which includes one or more virtual CPUs, virtual system memory, one or more virtual disks, one or more virtual devices, etc., all of which are implemented in software to emulate the corresponding components of an actual computer.

The virtual machines run on top of a hypervisor104(sometimes referred to as a virtual machine monitor, or VMM), which is a software interface layer that abstracts system hardware110into virtualized hardware, thereby enabling sharing of system hardware110of computer system100amongst the virtual machines. Hypervisor104acts as an interface between VM1021and system hardware110for executing VM-related instructions and for transferring data to and from machine memory120, processor(s)112, disk interface116, etc. Hypervisor104may run on top of an operating system of computer system100or directly on hardware components of computer system100.

In one embodiment, hypervisor104includes a page sharing module124configured to perform a page sharing process, according to one embodiment, on guest physical memory pages utilized by VM1021. As described in detail later, page sharing module124is configured to re-map guest physical memory pages assigned to VM1021and runtime environments108having the same contents to a same machine memory page122. For clarity of discussion, the term machine memory refers to actual hardware memory that is visible to hypervisor104. The term guest physical memory refers to a software abstraction used to provide the illusion of hardware memory to a VM. Guest physical memory is generally visible to a guest OS running on a VM. Guest physical memory is backed by machine memory and hypervisor104provides a mapping from guest physical memory to machine memory. The term guest virtual memory refers to a continuous virtual address space presented by a guest OS to applications running inside a VM.

VM1021is configured to support a runtime environment108running on top of guest OS106. To simplify the description, description of other VMs102Nare omitted but it should be understood that VMs102Nare configured similarly to VM1021. In the embodiments illustrated herein, runtime environment108is a Java Virtual Machine (JVM), although it should be recognized that other runtime environments and/or applications executing on top of the guest OS and having their own memory manager, such as databases, web servers, etc., may be used without departing from the scope of the teachings herein. The embodiments presented should therefore not be interpreted to be exclusive or limiting, but rather exemplary or illustrative.

Runtime environment108is configured to run one or more applications130to provide, for example, web services, database services, and other information technology services that may involve retrieval, processing, and serving of data to one or more users. To improve performance and reduce latency, applications130may utilize a cache library132that provides a mechanism for temporarily storing copies of data used by application130for later use. By way of example, data used by application130that are suitable for caching include web session data, object-relational mappings, database query results, and compiled byte code. According to one embodiment, cache library132is configured to coordinate with runtime environment108to store cache data in one or more objects created within memory that may also be used by a balloon agent128of runtime environment108, as described in detail below.

Runtime environment108of VM1021is configured to coordinate with hypervisor104to manage memory using a mechanism for balloon memory that performs page sharing procedures on guest physical memory pages utilized by runtime environment108. According to an embodiment, VM1021includes a balloon driver126installed in guest OS106and a balloon agent128within runtime environment108. Balloon driver126is a systems-level driver configured to communicate with hypervisor104and balloon agent128to exert memory pressure on runtime environment108. For example, when balloon driver126receives instructions from hypervisor104to inflate, balloon driver126requests balloon agent128to inflate, rather than requesting for memory pages directly from guest OS106.

Balloon agent128is a thread or process executing within runtime environment108configured to manage heap memory of runtime environment108. Responsive to commands and/or signals provided by hypervisor104via balloon driver126, balloon agent128inflates by allocating and freeing one or more objects within heap memory to effectively reduce the heap space that can be used by runtime environment108and any applications130running therein. A smaller heap may cause garbage collection of runtime environment108to run more frequently, which decreases throughput. Further, repeated allocation and discarding of objects within heap memory may further decrease performance of runtime environment108. As such, according to one embodiment of the present disclosure, balloon agent128is configured to retrieve objects within heap memory that are used by application130for storage cache data and repurpose the objects for use in ballooning. An example technique for implementing balloon memory is further described in more detail in U.S. patent application Ser. No. 12/826,389, filed Jun. 29, 2010, and entitled “Cooperative Memory Resource Management via Application-Level Balloon,” which is incorporated herein by reference.

FIG. 2illustrates, in greater detail, a VM1021configured to perform memory management techniques, according to one or more embodiments, while executing runtime environment108. Runtime environment108includes an interpreter202, a heap204, and a garbage collector210to support execution of one or more applications130within runtime environment108. Interpreter202is configured to translate and execute software code (i.e., byte code) of application130. Garbage collector210is a memory manager for runtime environment that attempts to reclaim heap memory occupied by objects in heap204no longer used by runtime environment108or applications130running therein. Heap204comprises a region of memory (referred to herein as “heap memory”) reserved for storing one or more objects (e.g., Java objects) and other data structures utilized during execution of application130. Heap204is illustrated in greater detail and described further in conjunction withFIG. 3.

Runtime environment108further includes a cache balloon manager206configured to allocate one or more cache objects214within heap204for use by applications130to cache temporarily data and for use by balloon agent128to occupy space within heap memory as a memory balloon. Cache balloon manager206provides a centralized interface by which both applications130and balloon agent128alike may request new cache objects214, access existing cache objects214, and perform other operations on cache objects214. Cache balloon manager206maintains states for each of cache objects214residing within heap memory that indicates the contents of cache object214, for example, that a given cache object214is available for storing cache data. Cache objects214are illustrated in greater detail inFIG. 3.

FIG. 3depicts a layout of heap204having cache objects214residing therein, according to one or more embodiments. While an embodiment based on OpenJDK, an open source JVM implementation from Oracle Corporation, is depicted, principles of the present disclosure can also be used with other JVM implementations.

Heap204is divided into regions of young, old, and permanent generations302,304,306, respectively. Permanent generation306holds static data, such as class descriptions, and has its own form of memory management. New objects are allocated into an “eden” space of young generation302. Once the eden space is exhausted, runtime environment108may start a minor garbage collection operation, where live objects (i.e., reachable) are copied into a “survivor” space. In the embodiment illustrated herein, there are two survivor spaces, which serve alternately as the destination of live objects from the eden space or from the other survivor space. Objects stay in young generation302until the objects live long enough to be promoted into old generation304, sometimes referred to as “tenured space.” When old generation304runs out of space, a major garbage collection happens and live objects are copied and compacted within old generation heap304to create free space.

Known techniques for application-level caching have used one of a variety of mechanisms of adding and removing temporary objects allocated within heap204. In one example, a cache may be implemented using soft-referenced objects, which are objects that can be garbage collected even though the objects are in use when garbage collector210determines that little to no memory (e.g., in old generation304) is available. However, it has been determined that this approach to caching leads to unpredictable performance costs due to the lack of control over garbage collection and the pause time incurred while garbage collection occurs. Further, it has been determined that known techniques for caching may not be responsive to memory management techniques used in virtualized environments with memory over-commitment. For example, a JVM executing within a VM may be unaware of outside memory pressure (e.g., from hypervisor) and may not release cached data in heap memory that would help the performance of the whole system, particularly if that JVM is relatively idle. As such, according to one embodiment, cache balloon manager206uses cache objects214within heap204to provide application-level caching when no memory pressure is being exerted by hypervisor104and deterministically removes the cached data from heap204without incurring the cost of garbage collection.

In one embodiment, cache objects214are wrapper objects that encapsulate one or more regions of data for use in application-level caching or in memory ballooning. In some embodiments, the data region for each cache object214is configured in a format that cache balloon manager206may determine a page address of an underlying guest physical memory page within heap204(e.g., via a Java Native Interface (JNI) call). In the embodiment shown inFIG. 3, the region of data for each cache object214is arranged as a byte array (e.g., byte arrays310,312), although other suitable data structures and formats may be utilized. Rather than allowing direct access to the data regions, cache objects214expose the one or more regions of data to applications130and balloon agent128using accessor and mutator methods (e.g., getRegion( ) setRegion( )). In some embodiments, data regions of cache objects214may be configured to store cache data, as illustrated by byte array312, or to be used as part of a memory balloon, as illustrated by the zeroed out byte array310.

Each cache object214includes a reference314to a data region (e.g., byte array) allocated within heap memory. In some embodiments, reference314may be configured as a soft reference, which denotes a type of object that may be taken away at the discretion of garbage collector210in response to memory demands. In one implementation, an accessor method (e.g., getRegion( )) of cache objects214may be configured to check if soft referenced data regions have been taken away, and may throw an exception if access to such a data region is attempted. While references314to data regions may be soft references, references to cache objects214themselves, such as those maintained by cache balloon manager206, may remain as strong references (i.e., hard references) to ensure tenancy of cache objects214within heap memory.

In some embodiments, cache objects214are wrapper objects configured to prevent synchronous access from both an application130and/or a balloon agent128. Cache objects214may further include additional metadata that facilitates memory management operations described herein. For example, cache objects214may include an internal counter indicating a number of times the cache object has been used for memory ballooning or for cache data, a timestamp indicating a date and time of last utilization, etc.

Returning toFIG. 2, balloon agent128is configured to request one or more cache objects214from cache balloon manager206responsive to memory demands from balloon driver126and hypervisor104. Balloon agent128is further configured to notify, or “hint” to hypervisor104that guest physical memory pages backing cache objects214as candidates for page sharing. In one implementation, balloon driver126may communicate with hypervisor104via a backdoor call and provides a page sharing hint comprising an address of a candidate guest physical memory page (e.g., a guest physical page number.) Accordingly, balloon agent128coordinates with balloon driver126and hypervisor104to utilize page sharing techniques on guest physical memory pages that are reserved for heap204and that may have been used for cache data by applications130.

In one embodiment, cache balloon manager206includes a listener component208configured to receive registrations from any applications130that have stored data in a particular cache object. Listener component208is further configured to notify the registered applications when that particular cache object is about to be affected, for example, re-purposed for ballooning, garbage collected, etc. In some embodiments, listener component208is configured to interact with registered applications130to enable applications130to veto an impending removal of cache data from the particular cache object214.

To enable access to one or more cache objects214managed by cache balloon manager206, cache library132of application130may use a utility library, such as a cache balloon library212, that is configured to provide an application-side interface (e.g., API) to cache balloon manager206. In some embodiments, functionality of cache balloon library212may be incorporated within cache library132or may be separate components as shown inFIG. 2. Operations of application130for caching data within heap memory using cache objects214is described in greater detail in conjunction withFIG. 4.

Example of Application-Level Caching

FIG. 4is a flow diagram that illustrates steps for a method of caching application data in a managed memory reserved to runtime environment108, according to an embodiment of the present invention. It should be recognized that, even though the method is described in conjunction with the systems ofFIG. 1andFIG. 2, any system configured to perform the method steps is within the scope of embodiments of the invention.

At step402, application130generates cache data to be stored within memory for later use. In step404, application130provides the cache data to cache balloon manager206to provision a cache object214that encapsulates the provided cache data. In one implementation, application130creates a byte array having the cache data stored therein and passes the byte array to cache balloon manager206. In some embodiments, application130utilizes a constructor method of cache balloon library212to obtain a cache object214for its use. Cache balloon library212in turn invokes cache balloon manager206to obtain a reference to a cache object214. Responsive to receiving the cache data from application130, cache balloon manager206may provision a cache object214from cache objects already existing within heap204or create a new cache object within heap memory. It should be recognized that application130may request provision of a cache object without providing cache data (e.g., via a default constructor method).

In step406, cache balloon manager206retrieves a list of existing cache objects214within heap memory. In some embodiments, the list of existing cache objects may include a plurality of “strong” references to cache objects214. In step408, cache balloon manager206determines whether any of the existing cache objects214are available for use. As described above, cache balloon manager206tracks the state of cache objects214that categorizes the contents of each cache object214. In some embodiments, a state of a cache object may indicate that the cache object is available for storing cache data, that a given cache object214is currently being used for balloon memory (i.e., unavailable), whether a given cache object214has been garbage collected. In some embodiments, a state of a cache object may indicate that a cache object is currently storing cache data for a particular application. Such cache objects may nonetheless be re-used for storing cache data of another application.

In step410, responsive to determining that no existing cache objects are available for storing cache data, cache balloon manager206creates a new cache object214within heap memory and proceeds to step412. In some embodiments, cache balloon manger206may set a state of cache object214within heap202indicating an availability of cache object214to store cache data. It should be recognized that step410may be performed by cache balloon manager206when there are little or no cache objects existing, such as at a time when a runtime environment108initially starts running. In one implementation, cache balloon manager206may allocate new cache objects according to a pre-determined cache size limit. In some embodiments, cache balloon manager206may continue to allocate new cache objects until a pre-determined size limit for all cache objects within heap memory has been reached. In some embodiments, cache balloon manager206may allocate new cache objects even though available cache objects exist within heap memory until the pre-determined cache size limit has been reached, at which point existing cache objects are re-used and re-purposed.

Newly-created cache objects214may be configured for a dual use in storing application-level cache data and for memory ballooning. In some embodiments, to facilitate page sharing, cache objects214may be created having an object size selected to be at least the size of one page of machine memory in system hardware110(e.g., 4 MB) though other sizes are possible, such as multiple pages of memory. Generally, the use of large objects reduces the number of objects balloon agent128needs to handle for meeting a large balloon target. However, because cache objects214are repeatedly re-used by both data caches and memory ballooning without incurring the cost of new object creation, embodiments of the present disclosure advantageously permit a smaller size of cache objects214to be selected to provide increased storage granularity and flexibility between data caching and memory ballooning.

Responsive to determining that at least one cache object214is available for storing cache data, in step412, cache balloon manager206identifies the available cache object and sets a data region of cache object214to store the received cache data. Cache balloon manager206allocates and includes a data region object (e.g., byte array) for cache object214. Alternatively, cache balloon manager206may store a reference to a pre-existing byte array provided by application130and containing the cache data. In embodiments where cache balloon manager206provides the data region objects, cache balloon manager206may copy data from a data structure (e.g., byte array) provided by application130into the data region of cache object214. In cases where a cache balloon manager206is not provided with cache data (e.g., via default constructor), a byte array is still allocated for cache object214and may be set (e.g., via a mutator method) at a later time. In embodiments where cache balloon manager206stores a pre-existing byte array provided by application130, cache balloon manager206may create a new wrapper object214to represent and track the state of the pre-existing byte array. In such embodiments, it should be recognized that application130gives up direct control of that byte array and later interacts with the byte array via wrapper cache object214. As described above, the reference to the data region of cache object214may be a soft reference to permit garbage collection to discard the cached data in response to memory demands. In step414, cache balloon manager206returns a reference to cache object214to application130. In step416, application130receives and retains the reference to cache object214that is now storing cache data. Data can only ever be read from or written to the cache by invoking wrapper methods on cache object214. In some embodiments, application130may choose to invoke the wrapper methods of cache object214to read and write certain portions, rather than the entirety, of the data region. In one implementation, application130invokes accessor and mutator methods (e.g., setRegion( ), getRegion( )) on any index in cache object214to read and write cache data to that portion of the byte array within cache object214. Cache balloon library212may be configured to track such indexes to maintain records of where cache data is stored within a particular data region of cache object214.

Cache data used by application130is generally some copy or version of persistent application-level data used primarily to improve performance of application130. As such, cache data may generally be discarded without affecting application state or operation, should computing resources (e.g., memory) become scarce. However, in some cases, application130may wish to create a copy cache data or perform some “last-chance” action just before cache data is discarded, such as a copy or saving operation. Accordingly, in some embodiments, in step418, application130may register with listener component208of cache balloon manager206to signal interest in cache data of a particular cache object214. In step420, cache balloon manager206modifies state of the referenced cache object to register application130. In some embodiments, cache balloon manger206may modify a central listing of cache objects to include an association between application130and one or more cache objects214storing cache data for application130.

Example of Memory Ballooning

Embodiments of the present disclosure provide a mechanism to repurpose Java objects storing application-level cache data within heap memory for management of memory assigned to the JVM and underlying VM. In some embodiments, the mechanism provides a memory balloon that “inflates” by re-using cache objects to store zeroed out memory pages within the Java heap and invoking page sharing on the zeroed out memory pages, as described further inFIG. 5.

FIG. 5is a flow diagram that illustrates steps for a method of managing memory assigned to a runtime environment, according to an embodiment of the present invention. It should be recognized that, even though the method is described in conjunction with the systems ofFIG. 1andFIG. 2, any system configured to perform the method steps is within the scope of embodiments of the invention.

In step502, balloon agent128receives a request to inflate balloon memory within runtime environment108. In some embodiments, balloon agent128may periodically poll for a new balloon target size from balloon driver126and determine whether the new target size for memory balloon is greater than or less than a current size of memory balloon. In another embodiment, the communication between balloon agent128and balloon driver126within guest OS106is through standard posix system calls.

In step504, balloon agent128requests one or more balloon objects from cache balloon manager206having a size within memory sufficient to satisfy the memory demands. In some embodiments, balloon object128may request a plurality of balloon objects having a pre-determined data region size that may be page shared to reclaim an amount of heap memory that satisfies the memory demand.

In step506, cache balloon manager206retrieves one or more available cache objects214allocated within heap memory. Cache objects214may be created anew or retrieved from a list of existing cache objects within heap memory. In some embodiments, a cache object214is deemed “available” for memory ballooning even though the cache object has a state indicating the cache object is already being used to store application-level cache data. As such, cache objects214are part of an “elastic” cache that permits its memory space to be reclaimed when VMs1021to102Nare under memory pressure from host100and hypervisor104.

In step508, for each retrieved cache object214, cache balloon manager206notifies any applications (e.g., application130) that have registered with listener component208of an impending deletion of existing cache data stored in a data region of each cache object. In some embodiments, cache balloon manager206may invoke a callback function that was provided by an application130during a registration process (e.g., performed in step418). In step510, response to notification of an impending deletion of cache data, application130may perform one or more actions using the cache data, for example, copying out the data to a more persistent or permanent location. In step512, application130may transmit an acknowledgement to cache balloon manager206to enable cache balloon manager206to proceed with overriding cache object for memory ballooning. In alternative embodiment, application130may transmit a “veto” signal, or request, that indicates cache balloon manager206should skip the retrieved cache object and attempt to use a different cache object for ballooning.

In step514, cache balloon manager206sets a data region of retrieved cache object214to a pre-determined value. In one implementation, cache balloon manager206invokes a mutator method (e.g., setRegion( )) of a particular cache object214to store a value within the data region of cache object214. In some embodiments, cache balloon manager206zeroes out (i.e., stores a zero value within) within the data region of cache object214to enable a page sharing process of guest physical memory pages assigned to heap204. In some embodiments, cache balloon manager206may set a portion of the data region of a cache object214sufficient to satisfy a memory demand indicated by balloon agent128. The portion may be less than the entire size of the data region to enable granularized control of a memory balloon. For example, in a case where balloon agent128calls for reclamation of 70 MB of heap memory, cache balloon manager may retrieve18cache objects having 4 MB data regions, zeroing out the data regions of17cache objects and only set a half portion of the data region of the 18thcache object,

In step516, cache balloon manager206updates state of the retrieved cache object214to indicate cache object214is being used as part of a memory balloon, e.g., a “ballooned” state. In some embodiments, cache balloon manager206sets a state for retrieved cache object214indicating at least a portion of the data region of retrieved cache object214has been zeroed out to be part of a memory balloon. Accordingly, such cache objects214are unavailable in any later requests for storing application-level cache data. In step518, cache balloon manager206returns references to the cache objects to balloon agent128. Balloon agent128may maintain a list of references to cache objects that make the memory balloon with heap204.

In step520, balloon agent128notifies hypervisor104of the data regions contained within received cache objects214having the pre-determined value to perform a page sharing operation. In some embodiments, balloon driver126may notify hypervisor104, for example, via a backdoor call, of the one or more guest physical memory pages containing data regions (“hinted memory pages”). The backdoor call may include page address of the hinted guest physical memory page (e.g., physical page number, or PPN).

Balloon driver126, balloon agent128, and hypervisor104subsequently perform an operation for page-sharing, as described in detail in U.S. patent application Ser. No. 12/826,389, specified above. For example, page sharing module124may maps the hinted guest physical memory page with a matched guest physical memory page to a same machine memory page122. Page sharing module220may modify one or more internal references in a page table to associate the hinted guest physical memory page with the matched memory page such that only one copy of the memory page needs be retained within machine memory120. That is, only one copy of the data region within heap memory needs to be retained within machine memory120. It is noted that if a later access attempts to modify the shared machine memory page122(e.g., later cache data) hypervisor104immediately makes a copy of the shared memory as per a copy-on-write (COW) technique. Hypervisor104reclaims a machine memory page122previously utilized by the hinted guest physical memory page assigned to runtime environment108and makes the de-allocated machine memory page available to other processes executing on host computer system100, such as other VMs and/or other runtime environments108.

According to one embodiment, to “deflate” the memory balloon for runtime environment108, balloon agent128releases cache objects from the memory balloon and enables them to be repurposed for application-level caching, as described inFIG. 6.FIG. 6is a flow diagram that illustrates steps for a method of managing memory assigned to a runtime environment, according to an embodiment of the present invention. It should be recognized that, even though the method is described in conjunction with the systems ofFIG. 1andFIG. 2, any system configured to perform the method steps is within the scope of embodiments of the invention.

In step602, balloon agent128receives a request to deflate balloon from hypervisor104. In some embodiments, balloon agent128determines a target size for balloon is less than a current memory size of runtime environment108. In step604, balloon agent128notifies cache balloon manager206that one or more particular cache objects214having zeroed value are no longer needed for memory ballooning. In step606, cache balloon manager206receives references to one or more cache objects214used by balloon agent128and an indication that the cache objects may now be available for other purpose (e.g., application level caching).

In step608, cache balloon manager206sets state of each received cache object214to an “available” state. Accordingly, cache objects214may continually be re-purposed for use as an application-level cache (as described in conjunction withFIG. 4) or as a memory balloon. As such, cache objects214configured according to embodiments of the disclosure persist in heap memory without having to constantly create and discard temporary objects, which may incur object creation costs or may invoke garbage collection.

Although one or more embodiments of the present invention have been described in some detail for clarity of understanding, it will be apparent that certain changes and modifications may be made within the scope of the claims. Accordingly, the described embodiments are to be considered as illustrative and not restrictive, and the scope of the claims is not to be limited to details given herein, but may be modified within the scope and equivalents of the claims. For example, runtime environment108may generally utilize guest virtual memory pages rather than guest physical memory pages and the backdoor call mechanisms (e.g., hypervisor-aware drivers within guest OS106, etc.) utilized by runtime environment108to communicate with hypervisor104that may translate guest virtual memory page references received from runtime environment108to guest physical memory page references prior to providing them to hypervisor104. In the claims, elements and/or steps do not imply any particular order of operation, unless explicitly stated in the claims.