InfoQ

News

JSR 284: Towards a "virtual Java virtual machine"

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

Community
Java
Topics
JCP Standards ,
Deployment / Datacenter ,
Performance & Scalability
Tags
JSR 284 ,
Isolates
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.

No comments

Watch Thread Reply

Educational Content

Bindings, Platforms, and Innovation

This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.

Orchestrating Long Running Activities with JBoss / JBPM

This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.

Neo4j - The Benefits of Graph Databases

This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.

Realistic about Risk: Software development with Real Options

This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.

Communication Flexibility Using Bindings

This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.

Writing DSLs in Groovy

After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.

Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)

IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.

Concurrent Programming with Microsoft F#

Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.