Browse Prior Art Database

Unchecked Reference: A Technique for Creating Inter-Tenant References

IP.com Disclosure Number: IPCOM000232456D
Publication Date: 2013-Nov-11
Document File: 4 page(s) / 48K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a novel technique for marking inter-tenant references that are allowed to violate the legal/illegal inter-tenant reference rules to accommodate instances where an inter-tenant reference needs to be created in a cloud environment that drives workloads through a Java* Virtual Machine (JVM).

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

Page 01 of 4

Unchecked Reference: A Technique for Creating Inter-Tenant References

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.

The novel approach is a technique that allows the JVM process to be shared safely by several applications (i.e., tenants) without compromising the isolation normally

found in dedicated-process JVMs. Sharing artifacts across JVM instances reduces the amount of physical resources required to run each application .

In a multi-tenant JVM, tenants must not be allowed to see the heap objects of other tenants. This is both for security reasons and for memory management purposes . For security, a tenant's heap data needs to remain private to that tenant. In relation to memory management, if a tenant's Java objects point at objects within another tenant, then two memory management issues are possible.

The first is that data locality becomes impossible to maintain . A region-based "balanced" garbage collector (GC) used in JVMs tries to maintain data locality by copying objects referred to by others into the same memory region as the associated referent. Because heap memory regions cannot be shared across multiple tenants if an object in one tenant's region is pointed to by another object from within a different tenant, this creates a situation where one of the tenant's data locality must be broken.

The second memory management issue posed by inter-tenant references is that if a tenant completes its execution and is no longer active, then references into that tenant's memory region from another tenant's, which are still active, prevent the recycling of the inactive tenant's memory regions which contain objects being pointed to from external tenants. The inactive tenant's supporting memory management data structures are also kept in memory for preservation until all of the tenant's objects have been collected. Therefore, this might lead to an out of memory situation when, in fact, a lot of memory remains available in the system

which, due to the configuration, is currently unusable. This issue can be solved via the modification of the Garbage Collection cycle to detect and move objects out of dying tenants; however, this is a complex and non-optimal approach.

In any case, even if security is not a concern, the creation of an inter-tenant reference is undesir...