Browse Prior Art Database

Optimized Tenant Aware Garbage Collection Disclosure Number: IPCOM000232459D
Publication Date: 2013-Nov-11
Document File: 4 page(s) / 76K

Publishing Venue

The Prior Art Database


Disclosed is a technique to control the resource usage of each tenant in a multi-tenant Cloud in order to limit the effect one tenant can have on the execution of applications in another tenant. This includes a method to bill the garbage collector time used on behalf of a tenant against Central Processing Unit (CPU) resource limits for that tenant.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 35% of the total text.

Page 01 of 4

Optimized Tenant Aware Garbage Collection

Heavily virtualized (a.k.a., cloud) computing environments are designed to realize cost savings by maximizing the density of applications that can be run per unit of hardware. This improves utilization rates of the hardware and energy efficiency by eliminating idle machines.

As a significant portion of workloads are written in Java*, it is critical that the Java

Virtual Machine (JVM) is adapted to recognize and exploit these virtualized environments. In order to maximize application density, the resource footprint of the JVM must be reduced, and the JVM must adapt to changing resource allocation, share more across JVM instances, and leverage hypervisor-specific functionality such as fast guest-to-guest network fabric.

Sharing artifacts across JVM instances reduces the amount of physical resources required to run each application. The novel technique described herein allows several applications (tenants) to safely share the JVM process without compromising on the level of isolation normally found in dedicated-process JVMs.

In multi-tenant Cloud Java, one of the key requirements is to control the resource usage of each tenant in order to limit the effect one tenant can have on the execution of applications in another tenant. In some Cloud Java implementations, tenants share a common heap. In these cases, the memory used by each tenant, and the Central Processing Unit (CPU) resources consumed by the garbage collector on behalf of the tenant, must be constrained to prevent impacting the operation of other tenants (e.g., by allocating and holding Object that consumes all available memory or triggering repeated garbage collects that consume all CPU resources). When a region- based collector is used, the memory used in the heap by each tenant can be controlled by limiting the regions available for allocation for each tenant and ensuring that all objects allocated by a tenant are allocated only in the regions it owns. For example, if a limit of 100MB has been set for a tenant and each region is 1MB, then the tenant is limited to use 100 regions. Resource constrained environments such as Java Micro Edition (ME) have used these kinds of techniques to constrain resource usage.

Despite being limited in the regions that a tenant can consume , without additional

techniques the tenant can still affect other tenants through its use of the regions available to it. For example:

• Rapid object creation/freeing of objects can result in the cause garbage collector consuming a large amount of CPU resources

• Repeated Out of Memory (OOM) instances can cause frequent, potentially global garbage collections. (There might be enough space for other tenants, so a collection is not needed, but the specific tenant has used all of the space associated with it.)

• Simply holding onto many objects can cause increased CPU usage if the objects have to be walked during every garbage collection

To minimize this potenti...