Browse Prior Art Database

Optimized Monitor isolation for a multitenant JVM using lockword field in Objects

IP.com Disclosure Number: IPCOM000240124D
Publication Date: 2015-Jan-05
Document File: 4 page(s) / 53K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a technique that allows users to use a lockword in the Object header in order to optimize locking in multi-tenant Java virtual machines (JVM) while ensuring that it appears logically that tenant has its own monitor for each Object.

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

Page 01 of 4

Optimized Monitor isolation for a multitenant JVM using lockword field in Objects

Java and Java virtual machines (JVM) provide support for synchronization/locking as part of the core language. Logically, every Java Object has a monitor associated with it that is used to provide synchronization as well as support for wait/notify semantics. While operating systems provide services that can be used to implement monitors , allocating operating system constructs for every Object is too expensive in terms of memory footprint. Similarly, calling operating system services for every synchronization event in the Java code imposes far too much runtime overhead.

A brief overview of the optimization typically employed is:

1. Each Java object includes a lockword field. Unless synchronization is done on this object, this is the only overhead required in order to provide locking support.

2. The lockword is used with compare/exchange and is atomically modified such that users can handle non-contended cases and cases in which threads waiting for a lock to be released only need to wait a short time before the lock is released . A thread can do a compare/exchange to acquire an unowned lock and to later release the lock, provided no other thread tried to acquire the lock while the thread held it. If a thread tries to acquire a lock that is already owned, it "spins" for a defined number of times, retrying each time it spins. If the lock is not available before it exceeds the maximum number of spins , then the lock is marked for "inflation".

3. When a lock marked for inflation is released by a thread , operating system resources are allocated and through a transition sequence in which all threads, either holding or trying to acquire the lock participate, use of the lockword is transitioned to the use of operating system synchronization constructs and services

4. When a thread releases an inflated lock and there are no threads waiting to acquire the lock , it can be "deflated". This process transitions back to using the lockword instead of the operating system lock constructs and services.

One of the current challenges is to improve "density" such that systems can run more applications on the same hardware in order to reduce energy use and management costs and improve overall cost/benefit per system. This is particularly important for deploying applications in Cloud systems and integrated systems environments. Since there is an overhead for each JVM instance, one way to improve density is to allow multiple applications to run in the same JVM, while providing a sufficient level of isolation. This is the goal of the Java "multitenancy" effort.

In order to achieve benefits of running in a single JVM, some artifacts must be shared across "tenants" (each tenant is an application that would have previously been run in its own JVM). In particular, sharing Java Class objects for classes which form part of the class libraries shipped with the JVM as well as clas...