JSR 284: Towards a "virtual Java virtual machine"

Posted by Floyd Marinescu on Aug 30, 2006 02:22 PM

Community

Java

Topics

Performance & Scalability,

Deployment / Datacenter,

JCP Standards

Tags

Isolates,

JSR 284

The first early review draft of JSR 284: Resource Consumption Management API has been posted for review.  The spec is being led by Google and it aims to bring to the Java platform some of the same abilities to manage computational resources is found in OSes - and doing it from within the Java language.  InfoQ spoke to spec lead Greg Czajkowski. "In some respects this is a step towards "virtual Java virtual machine", where a single instance of the JVM can host programs whose data and performance can be isolated from one another."    Greg sees the main products that might implement the spec be application servers, desktop systems that manage multiple computations (e.g., Java Desktop), telco systems, applications that need to provide various classes of service to different kinds of requests.

JSR 284 defines an API that enables resource management policies to be programmed, monitored, and reacted to. Resources include how much CPU or HEAP time, open JDBC connections or transactions per second it an application should have.  The framework offers per-thread resource management or management of application units called isolates, as defined in JSR 121. "An isolate is an encapsulated Java program or application component that shares no state with other isolates." The Isolate concept was first proposed to the JCP in 2001 and finally reached final status this past June.   The API framework also allows you to

On what JSR 284 will allow you to do (from the JSR page):

The API should enable resource management policies to be programmed. In particular, such a policy should have the ability to define when an application may gain access to, or consume, a unit of a specific resource. It should be possible to bind computations dynamically to policies. Programs should be able to reserve resources in advance and thus ensure predictable execution. Applications should be able to install resource monitoring code so that proactive programs can observe resource availability and take any actions required to ensure performance and availability or to ward off denial of service attacks.

On how the spec will address enforcement and reaction to policies, Greg replied:

The JSR defines two reactive components: constraints and notifications. Each of them is programmable. Constraints and notifications are essentially callbacks triggered by resource consuming events. Their arguments include the current and proposed resource usage. Constraints can influence the quantities of resource given to computation (e.g., "reject the request", "give two units instead of five", etc.). Notifications do not influence the requests.

Greg told InfoQ why he is most excited about this JSR:

This JSR equips Java with features really useful when constructing all sorts of application management environments. With this JSR we are one step closer to the ideal of making Java a complete computing platform. It was a great experience to lead the Expert Group composed of people who feel passionately about Java being able to throw away such crutches as native code and scripting glue and start walking on its own in the systems programming domain.

JSR 284 requires that all compatible implementations manage CPU time on per-thread basis.  JSR defines JMX bindings so that some of the functionality will be available directly through JMX. Beyond CPU time, management vendors are also free to expose any resources they feel like. "We are not mandating any other resources, but provide a convenient context for exposing them and for managing them in uniform ways. Sort of "no more malloc()/setrlimit", but a unitform, OO view of resources that gracefully fits the language," Greg concluded.

• Older >